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!
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 ?