Eclipse PDE Cycles with Spring-DM

[topherfangio]

Hello all,

We are building an Eclipse RCP based application and would like to upgrade to the latest release of the spring-osgi integration bundles (Spring-DM). We are experiencing a particular problem with cyclical dependencies and I was wondering how the community would suggest moving forward.

Basically we are having the same problem as described in the following post: post id = 63250, title = "Classpath cycle" (it won't let me post a link to it until I have at least 5 posts). However, we are experiencing it with core and context instead of context and orm. Our dependencies look like this:

Our plugin -> org.springframework.bundle.osgi.core_1.1.2 -> org.springframework.bundle.spring.context_2.5.5 -> our plugin since it is the easiest way to depend on org.springframework.bundle.osgi.core_1.1.2.

In the post mentioned above, they simply hacked the manifest file to remove the dependency since it was optional. Now, whilst this method is not ideal since we would have to change it every time we upgrade to the latest bundles, I would be willing to do it if someone could confirm that the dependency cycle we have is optional and that this is a valid work-around.

Any ideas or thoughts?

[topherfangio]

So, it turns out that this was not in fact the case but that there was another error.

org.springframework.bundle.spring.context imports javax.jms which our plug-in was exporting, thus the direct dependency. I thought things were odd, but until I started removing dependencies from the manifest file manually, I didn't realize what was going on.

Sorry for posting an erroneous question!

[topherfangio]

So now we're having the problem that I originally stated except it's with different bundles:

Problems during export
  A cycle was detected when generating the classpath

our.awesome.plugin_1.0.0, org.springframework.bundle.osgi.extender_1.1.2, org.springframework.bundle.osgi.extensions.annotations_1.1.2, org.springframework.bundle.osgi.extender_1.1.2

If I use the plug-in dependencies view or the graph view, it shows a direct dependency from extender to annotations and back again. So, I guess my question is pretty simple: are there plans in the works to correct these direct dependencies?

[Costin Leau]

Nice catch. It's hard to break this dependency since the extender bootstraps the code and thus needs to be aware of various packages to be able to load classes from them (otherwise, it cannot enable annotation scanning). The annotation package on the other hand uses on some extender interfaces to add certain functionality.
In terms of modules there is a dependency but in terms of packages there isn't any. I'd like to eliminate the problem but on the other hand I don't want create a lot of small bundles just to eliminate some warnings...
Please raise an issue to keep an eye out for this one - maybe we'll manage to solve it w/o creating too many bundles.

[topherfangio]

Thanks for the reply. I will definitely raise an issue and attempt to work around the problem for now.

[gengshg]

Hi topherfangio, Contin

I can see what happened within your work. I think spring.context import javax.jms was nothing wrong, but your app export javax.jms is not really good.

I think OSGi has provide us with a very smart architecture that we are easier find what is in a cycle.

For your case, I really suggest that javax.jms(base interface) should be exported from bottom. You app is at top side, spring.context is at middle. So you export javax.jms and import spring.context is really something wrong.

OSGi/DM app needs analyse from architecture point of view, after which, a good design is archieved.

Yours.