Community
Participate
Working Groups
Build ID: Can be found on Eclipse 3.4 Steps To Reproduce: 1.Create a plugin project 2.Add a dependency on the manifest file and point to a binary plugin (a plugin that is already compiled) that has a circular dependency with another binary plugin. 3. Try to export the plugin using the Export task (Export as Deployable plug-ins and Fragments) Results: you will get an error message similar to this: Problems during export A cycle was detected when generating the classpath com.ibm.director.wparmgt.common.core.services_1.0.0, com.ibm.usmi.kernel.USMIKernel_1.0.0, com.ibm.usmi.services.slp_1.0.0, com.tivoli.twg.legacylibs_1.0.0, com.ibm.usmi.kernel.USMIKernel_1.0.0. A cycle was detected when generating the classpath com.ibm.director.wparmgt.common.core.services_1.0.0, com.ibm.usmi.kernel.USMIKernel_1.0.0, com.ibm.usmi.services.slp_1.0.0, com.tivoli.twg.legacylibs_1.0.0, com.ibm.usmi.kernel.USMIKernel_1.0.0. More information: This problem is related with bug 208011. There is a fix that was introduced on Eclipse 3.4 to allow PDE build to export plugins with circular dependencies on binary plugins (see comment #13 from bug report). This works for headless builds but it does not work when the plugin is exported from the UI. The export task does not read the allowBinaryCycles property from the build.properties that is part of the project.
To clarify, the "allowBinaryCycles" property is set in the build configuration build.properties for a headless build. (Even headless build does not read it from the bundle's build.properties file). For UI to set this, in FeatureExportOperation#setupGenerator they would need to call generator.setImmutableAntProperties(properties), with a properties object containing allowBinaryCycles set to true.
So this option can only be turned on/off for the whole build process? It can't be done on a per bundle basis? If we search the build.properties file for this option and it is turned on for one bundle, but turned off for another in the same export, what option should be the default?
Build does not support this on a per-bundle basis. For UI to set it based on the contents of the bundle's build.properties would be misleading if headless build does not support the same. And, if headless build did support it, then there would be nothing for UI to do. So the options would be: 1) UI sets the option always for everyone (or perhaps based on a preference) 2) Send this back to build to support it on a per-bundle basis.
Andrew, what is the negative of always setting this? What trouble can we get into?
Build's implementation of this is in cases where we would have failed with a "A cycle was detected..." message, for some cycles which we can identify as something we can compile, we instead allow the build to continue. So worst case would be if we mis-identified the cycle as compileable you would get compile errors instead of the cycle message.
I really hate cycles :) However, I'm comfortable with always enabling this as I think this doesn't happen much in the wild. What do you think Andrew? I don't know if it's worth it on your end to implement this on a per-bundle basis.
Hey guys, As I see it there are several scenarios that need to be covered if you guys decide to make it configurable. The scenarios are: 1. Exporting a single plugin selected by the user 2. Exporting multiple plugins selected by the user. 3. Exporting a feature. If this is something that is not going to be read from the build.properties file in the project then it would be nice if it was an option that the user can select when using the Export wizard. Currently there are some options that are exposed through the wizard (i.e. Package plug-ins as individual jars) so this would be an additional option that would have to be exposed. I am not sure if there is a different implementation for exporting a feature but this option would also have to be exposed when exporting a feature.
The property to turn this on is IBuildPropertiesConstants.PROPERTY_ALLOW_BINARY_CYCLES == "true" This needs to be added to a Properties object and set on the generator with generator.setImmutableAntProperties(). I would have suggested adding the property in createAntBuildProperties and passing that to generator.setImmutableAntProperties(properties) but setImmutableAntProperties takes a Properties object, and createAntBuildProperties creates a HashMap. You could either change createAntBuildProperties to return a Properties, or make a new properties to pass to the generator.
mine
done. > 20091026
There's a new option when you export a feature, plug-in or product to allow for binary cycles in the target. This option is ON by default. I hope this helps you Jorge.
Which files were changed to enable this option? What would it take to backport similar behavior to 3.4.x?
(In reply to comment #12) > Which files were changed to enable this option? What would it take to backport > similar behavior to 3.4.x? > Since 3.4.2 is moving into release candidate builds today, there is no way we are going to be able to backport this new behaviour. I do not have an exact list of files that were changed, but they include FeatureExportOperation and subclasses as well as ExportOptionTab/ProductExportWizardPage for the UI changes.
I just tried this with the latest 3.5 integration build. Works nicely. However, you get the same "cycle detected" error if you right-click plugin.xml and select PDE Tools > Create Ant Build File.
I opened bug 266139 for the Ant build problem.
