Community
Participate
Working Groups
Build Identifier: M20100818-0800 In our adopter product we see a problem with the default Ant home. The directory is getting resolved to one of our own plugins. I did a bit of debugging, and for some reason the packageAdmin.getExportedPackages("org.apache.tools.ant") call seems to be returning four plugins, the org.eclipse.ant one and three from our adopter. Yet the three from our adopter do not export org.apache.tools.ant so I am not even sure why they are there. Also it appears that because it is one of ours that occurs first in the list, it is the one that gets setup up as the ant home incorrectly. This breaks our ant function by default and is a regression from 3.4.x. I can't tell you how to repro as I am not sure why it thinks these three bundles export the tools.ant, however I can repro so I can help gather the info you would need. Reproducible: Always
I did some additional digging, and my original investigation wasn't 100% correct. Our plugins do have jars in the Referenced Libraries that contain the org.apache.tools.ant, and those jars are exporting the entire library. I am now going to check to see if this is also the case in our 3.4.x based product as perhaps it was a change to our plugin that resulted in this behaviour.
OK hopefully here is the details that will be required to address this issue. So here is the higher level problem and repro: An error message is displayed when trying to build Update Site or a Feature with option "Generate metadata repository". The build is unsuccessful. Steps to reproduce (with Feature): 1. Create new Feature project. 2. Open feature.xml and click "Export a deployable feature". 3. Choose "Generate metadata repository" on "Options" tab. 4. Click "Finish". Steps to reproduce (with Update Site): 1. Create new Update site project. 2. Open site.xml and add some feature. 3. Choose "Build All". Error report details for building feature: <status code="1" message="C:\workspace\FeatureA\assemble.FeatureA.p2.xml:29: The following error occurred while executing this line:
C:\workspace\FeatureA\assemble.FeatureA.p2.xml:39: The following error occurred while executing this line:
C:\workspace\FeatureA\assemble.FeatureA.p2.xml:15: The following error occurred while executing this line:
java.lang.NoSuchMethodError: org/apache/tools/ant/types/FileSet.getDirectoryScanner()Lorg/apache/tools/ant/DirectoryScanner;" plugin-id="org.eclipse.ant.core" plugin-version="3.2.200.v20100427" severity="4"> <exception message="The following error occurred while executing this line:
C:\workspace\FeatureA\assemble.FeatureA.p2.xml:39: The following error occurred while executing this line:
C:\workspace\FeatureA\assemble.FeatureA.p2.xml:15: The following error occurred while executing this line:
java.lang.NoSuchMethodError: org/apache/tools/ant/types/FileSet.getDirectoryScanner()Lorg/apache/tools/ant/DirectoryScanner;" type="org.apache.tools.ant.BuildException"> <trace class="org.apache.tools.ant.ProjectHelper" method="addLocationToBuildException"/> <trace class="org.apache.tools.ant.taskdefs.Ant" method="execute"/> <trace class="org.apache.tools.ant.taskdefs.CallTarget" method="execute"/> <trace class="org.apache.tools.ant.UnknownElement" method="execute"/> <trace class="org.apache.tools.ant.Task" method="perform"/> <trace class="org.apache.tools.ant.Target" method="execute"/> <trace class="org.apache.tools.ant.Target" method="performTasks"/> <trace class="org.apache.tools.ant.Project" method="executeSortedTargets"/> <trace class="org.apache.tools.ant.Project" method="executeTarget"/> <trace class="org.apache.tools.ant.helper.DefaultExecutor" method="executeTargets"/> <trace class="org.eclipse.ant.internal.core.ant.EclipseDefaultExecutor" method="executeTargets"/> <trace class="org.apache.tools.ant.Project" method="executeTargets"/> <trace class="org.eclipse.ant.internal.core.ant.InternalAntRunner" method="run"/> <trace class="org.eclipse.ant.internal.core.ant.InternalAntRunner" method="run"/> <trace class="sun.reflect.NativeMethodAccessorImpl" method="invoke0"/> <trace class="sun.reflect.NativeMethodAccessorImpl" method="invoke"/> <trace class="sun.reflect.DelegatingMethodAccessorImpl" method="invoke"/> <trace class="java.lang.reflect.Method" method="invoke"/> <trace class="org.eclipse.ant.core.AntRunner" method="run"/> <trace class="org.eclipse.pde.internal.core.exports.FeatureExportOperation" method="runScript"/> <trace class="org.eclipse.pde.internal.core.exports.FeatureExportOperation" method="doExport"/> <trace class="org.eclipse.pde.internal.core.exports.FeatureExportOperation" method="doExport"/> <trace class="org.eclipse.pde.internal.core.exports.FeatureExportOperation" method="run"/> <trace class="org.eclipse.core.internal.jobs.Worker" method="run"/> We were informed this was very likely just an ant version mismatch between what was in org.apache.ant.version and what was being used by Preferences -> Ant -> Runtime -> Ant Home which does appear to be case case. I think the core problem is in the following area: ExportedPackage[] packages = packageAdmin.getExportedPackages("org.apache.tools.ant"); //$NON-NLS-1$ Bundle bundle = findHighestAntVersion(packages); if(bundle == null) { for (int i = 0; i < packages.length; i++) { bundle = packages[i].getExportingBundle(); if(bundle == null) { continue; } try { addLibraries(bundle, result); if(result.size() > 0) { break; } } The getExportedPackages will indeed return the ant plugin in addition to three of our plugins that export ant. However the version we export is older than what is in the ant plugin. In findHighestAntVersion because it finds providers other than just the ant plugin, it returns null. However that means that in the above loop it will just pick the first package that exports, and in our case that is an older version than the ant plugin. Please let me know if this all does/doesn't make sense.
(In reply to comment #2) > The getExportedPackages will indeed return the ant plugin in addition to three > of our plugins that export ant. However the version we export is older than > what is in the ant plugin. In findHighestAntVersion because it finds providers > other than just the ant plugin, it returns null. However that means that in the > above loop it will just pick the first package that exports, and in our case > that is an older version than the ant plugin. > > Please let me know if this all does/doesn't make sense. This makes perfect sense and is working as designed. The reason we return null in the case of other providers re-exporting is because we cannot rely on the actual version of Ant being available for comparison. For example if you have Ant 1.7.1 installed and ProdA 3.5.4 and ProdB 5.8 that re-export Ant, a blind comparison of versions would say ProdB should be used, but in fact ProdB might have the lowest version of Ant classes - similar to what is happening in your scenario. Out of curiosity, is there a need for your bundles to re-export Ant? Ant is part of the platform so you should not have to do so. Perhaps we could look at adjusting the logic a bit in our code in the case of there being N exported packages and not all of them are from org.apache.ant. Related bugs are bug 167291 (where this all started), bug 275839 one of the 'new logic fixes', and bug 282851 the latest changes to the logic to check and see if there are jars in the provider we are considering.
I spoke with our team, and the way this is exported would not be easy for us to prevent. We get a number of jars from another team, and those jars are then packaged into our plugins and exported. There is a ton of stuff in these jars (that are very black box for us) that others require, so we export at the jar level. One of the things contained within is Ant, however as mentioned in the plugin it happens to pick up first, it has an older version of Ant. This would be very hard for us to control from our side. Is the intention to allow anyone to export Ant and that any of those exported could be used? Given the version of Ant from another plugin cannot be determined, is there a reason why we shouldn't default to the one from the org.apache.tools.ant instead of leaving it to chance on which one we use to set up the ant home? Please keep in mind, I may not be fully understanding all the changes so I may be way off. :)
(In reply to comment #4) > Is the intention to allow anyone to export Ant and that any of those exported > could be used? Yes, that is why we have no logic to ask where Ant is coming from - i.e. if it comes from org.apache.ant. > Given the version of Ant from another plugin cannot be > determined, is there a reason why we shouldn't default to the one from the > org.apache.tools.ant instead of leaving it to chance on which one we use to > set up the ant home? I was thinking along the same lines that perhaps we could update our logic to something like: 1. if there is one ant - just use it 2. > 1 then: 2a. are they all org.apache.ant? - compute the highest version 2b. are a subset (one or more) of them org.apache.ant? - collect those and compute the highest version 2c. if no in 2b choose the first one. The proposed logic is very similar to what we have now, except for 2b.
I think this would work for us, and I think seems like the preferred way to have these things evaluated.
Created attachment 180174 [details] proposed fix The patch is a simple fix, we now whip over all packages named org.apache.ant to try and find the highest version, failing that, we try the other providers, starting with the first.
Darin, Robert, please verify.
Patch looks good.
Worked for me as well. Thanks guys.
Created attachment 183908 [details] Plugin for 3.6 stream with the patch It may be necessary to request backporting this patch into 3.6 stream, as this issue affects Eclipse adopters. This is plugin for testing if this patch helps also in 3.6 stream.
(In reply to comment #11) > It may be necessary to request backporting this patch into 3.6 stream, as this > issue affects Eclipse adopters. This is plugin for testing if this patch helps > also in 3.6 stream. This has already been done. See bug 326958.
*** Bug 256860 has been marked as a duplicate of this bug. ***
