Announcement Announcement Module

Spring Dynamic Modules forum decommissioned in favor of Eclipse Gemini Blueprint

With the official first release of Eclipse Gemini Blueprint shipped, the migration of the Spring Dynamic Modules code base to the Eclipse Foundation, as part of the Gemini project, has been completed.

As such, this forum has been decommissioned in favour of the Eclipse Gemini forums.
See more
See less
Eclipse PDE Cycles with Spring-DM Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Eclipse PDE Cycles with Spring-DM

    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?

  • #2
    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!


    • #3
      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?


      • #4
        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.


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


          • #6
            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.



            • #7

              I realize now that my initial problem was in fact my own error. Our main plug-in was exporting javax.jms on which the spring.context plug-in depended; thus why it had a direct dependency on our plug-in.

              I extracted the jms stuff into it's own plug-in and everything was handy dandy. Now, the only problem I have is the dependency between the extender and annotations bundles. This really isn't a big deal since I can manually change the manifest since it is an optional dependency, but it would be nice if the next time we upgrade, we wouldn't have to remember to modify the manifest file.


              • #8
                Okay. I have been working on an automated build system recently, so I decided to wait until I absolutely had to fix this problem. So, the other day I actually had to hack the manifest file.

                I tried a few different ways including importing the bundle into Eclipse, changing the manifest, and then I was going to re-export the plug-in, but it simply won't let me. The other thing I tried was importing the plug-in into Eclipse, updating the manifest, extracting the plug-in using IZArc, and replacing the manifest file with the updated one, then re-jarring the plug-in. This didn't work because IZArc somehow corrupted the file. Then, I attempted the same thing except I used an Ant jar task to jar up the file instead of IZArc. Still, it caused corruption.

                I really don't want to have to recompile the entire SpringDM. Anybody have any suggestions?


                • #9

                  Hello everyone,

                  I finally resolved my issue. Here are the steps I took to fix the problem:
                  1. Imported org.springframework.bundle.osgi.extender as a binary project in Eclipse inside of my workspace with all of the other plug-ins I was building.
                  2. Opened the MANIFEST.MF file and removed the optional dependency on org.springramework.bundle.osgi.extensions.annotati ons.
                  3. Exported my product which had the org.springframework.bundle.osgi.extender plug-in listed in the configuration.
                  4. Grabbed the org.springframework.bundle.osgi.extender_1.1.2.jar file from the plugins directory of the exported product.
                  5. Copied/pasted that back into my target.
                  6. Deleted the binary project (org.springframework.bundle.osgi.extender) that I previously imported.
                  7. Re-ran the build/export.

                  Everything worked great after following these steps!

                  Thanks for all of your comments and suggestions!


                  • #10
                    As explained in this thread (, you now have an option to allow cycles inside PDE:

                    Enable "allow for binary cycles in the target platform" - see

                    To quote:
                    Allow binary cycles in target platform is an option that controls how the export operation deals with cycles in the dependency graph for a plug-in. PDE Build cannot compile if a cycle is detected. However, if a cycle only contains binary plug-ins from the target platform, turning on this option will allow PDE Build to continue.