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!