on Oct 28th, 2008Tip: PDE Build and Binary Cycles
I recently spent some time with a client removing some cycles in bundles and discussing why cycles are evil in the first place. The problem is that even if you remove cycles from your own code, the code you depend on may not be cycle-free. This could be for many reasons, most of the time it’s due to legacy. So after some bundle cleansing, we setup an automated build… and had this dreaded error message come up in the logs:
“A cycle was detected when generating the classpath…”
I was sure this time that the fault didn’t lie with my client’s code, but someone else. I was right… the messy world of third-party dependencies can bring in some interesting baggage. This error was caused by a few third-party libraries that participated in a cycle, which is OK during runtime, even though poor architecture in my opinion. So how do you get around this? In the past, it was difficult in the Eclipse-world, but since 3.4, PDE Build was enhanced to allow binary cycles (cycles in the target you’re building against). To enable support for this, you simply have to specify the ‘allowBinaryCycles=true‘ in your top level build configuration properties, similar to where you specify properties like baseLocation. As of 3.5M3, PDE UI will automatically enable binary cycles support and this option can be toggled via the UI:
Hope this helps! Happy building and avoid cycles when you can!
Related posts:
- PDE Build Compile Errors
- How to build a RAP application with Tycho
- Announcing a full featured PDE Build example from a Git repository
- How to build a Server-Side Equinox/RAP Application
- Tagging Eclipse for the next integration build
What about this one:
* Plugin A
* Plugin B (depends on A)
* Fragment C (Host: A, depends on B)
If you have all three loaded in your workspace, PDE won’t be able to build the product because of cycles (3.4/3.5M2). Will that be fixed as well?
Actually, you have a dependency but only because of the fragment. A and B can be compiled fine. The fragment is optional and can be compiled later. It just contributes an implementation to A which will be used by B *if* it is available.
hi chris,
you made my day – thanks for this enhancement I was wishing since some time.
…seems that personal experiences sometimes fixes bugs sooner then reporting by bugzilla
in my OSGI enterprise application I always run into this problem with 3rdParty bundles like SLF4J-API, EasyBeans, …
alone this bugfix is reason enough starting with 3.5M3 for daily work
ekke
BTW: I had just prepared something to show you on Eclipse Summit Europe to demonstrate how hard it is to live with these 3rd party cycles. now perhaps I can show you some of my well-running things instead…
ekke
@Gunnar, the key word is the “workspace.” Since these artifacts exist in the workspace, it won’t work
I also assume your fragment is using Eclipse-ExtensibleAPI which is causing the cycle?
@Ekke, good to hear! We should still talk at ESE to see how we can simplify your development workflows.
“…and discussing why cycles are evil in the first place….”
Can you detail how you convinced your client that cycles are evil in the first place ?
Thanks a lot!
This made my day!
I was going crazy over these nasty cycle errors in my pde build.
Seems like the Spring bundles have a lot of these cycles..
genericTargets.xml:88: A cycle was detected when generating the classpath com.mycompany.bundle, org.springframework.bundle.spring.tx_2.5.5,com.mycompany.bundle
Thanks!
Sebastian
This seems pretty much what I need at the moment, however so far I am using ant to build an Eclipse RAP project, along with the “pde.exportFeatures” ant task, and I wonder how to make the ant task respect this settings as well… do you have any idea how to get this done? The “naive approach” (adding the “allowBinaryCycles=’false’” as an attribute to the ant task definition) didn’t work…
Thanks in advance,
K.
Kristian, I believe it’s an immutable ant property.
So you need to use the <property> tag.
Thanks a bunch for your comments, Chris. Unfortunately, trying it using the tag seemed to be unsuccessful as well. Gonna dig through this once more to see whether I can find anything else…
Thanks anyway.
K.
Kristian, it could be the way you’re invoking the ant task, rather than running a full PDE build. I think this option is only available when you do a full PDE Build. One option for you is to file a bug against PDE Build and we can start from there.
Thanks!
Great !! I was putting this property in build.xml which is wrong. Now fixed it.
Wasted so many days.
Thanks a ton !!!!!
Chris, I’m seeing this error when right clicking on a feature.xml file and choosing PDE Tools > Create Ant Build File. There’s no chance to inject an Ant property definition/override via that mechanism. How does one get around the problem in this scenario?