Community
Participate
Working Groups
I20110104-0920 While trying to find all of the dependencies on org.apache.ant in the platform I found that org.eclipse.jdt.apt.core has a dependency on Ant [1.6.5,1.8.0). This will cause problems once the platform consumes Ant 1.8.2 (see the CQ: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=4727). Is there something special APT needs from the 1.7.x versions of Ant? Can the upper bound just be removed?
Created attachment 186219 [details] Proposed fix
Walter, I can release that for you. Simply confirm that there is no possible side-effect by removing the upper bound.
I think apt.core should refer to ant code the same way jdt.core did for the ant adapter and provide the ant task in a separate jar file. The bundle itself doesn't need a dependency on apache.ant. I'll work on refactoring it properly.
Created attachment 186272 [details] Proposed fix This patch completely removes the dependency on apache.ant. It moves the ant task into a separate jar which is needed if I well understood for class loading purpose. It properly defines an ant task extension point. The only drawback is that the ant task type was defined as API is considered as removed from the API Tooling standpoint. I wonder if this class has ever been used as it is not defined in its own jar as all ant tasks defined in other bundles. Walter, please review. If no answer, I'll release the previous patch for the next I-build.
+1. Thank you, Olivier.
Walter, do you take care of releasing it for next I-build + tagging of the apt project ?
Yes, I'll make sure to do that this weekend.
I am a little concerned about API impact. The documentation (org.eclipse.jdt.doc.isv/guide/jdt_apt_building_with_apt.htm) states that AptBuilder is in aptcore.jar, and it looks like the export_plugin.xml build script is set up to create aptcore.jar, but I think this has been dead since Eclipse 3.2. Presumably people who use this have figured out how to put the apt.core plugin jar on their Ant classpath. So, if we take this class out of the plugin jar, we probably need to update the documentation and put something into the What's New; but since it's broken right now I am not sure what the right instructions for headless building with JdtApt should be. Also we should probably get rid of that export_plugin.xml code. And there don't seem to be any tests for these entry points. Yuck! The alternative is to leave things as they were, and just update the Ant requirement in the manifest. I've confirmed that Ant 1.8.1 contains all the classes we need (1.8.2 was just released and I've not checked it, but I can't believe they'd be getting rid of these classes). So we can probably just change the dependency to [1.6.5,1.9.0), or even just get rid of the upper bound as Michael suggests. Thoughts, Olivier? Realistically I am not going to have much time to test code changes, even though I agree this is a cleaner approach.
My concern is that the ant task defined in apt.core is useless as is since it is not separated from bundle's code. Walter, did you actually try the headless build in the past using the ant task? I am fine to limit the change to only get rid of the upper bound, but another bug should be open to clean this.
I removed the upper bound. Released for 3.7M5. I'll open a new bug to clean up the ant task definition in apt.core.
Open bug 333887 to track down the ant task definition inside apt.core.
(In reply to comment #9) > My concern is that the ant task defined in apt.core is useless as is since it > is not separated from bundle's code. Walter, did you actually try the headless > build in the past using the ant task? > > I am fine to limit the change to only get rid of the upper bound, but another > bug should be open to clean this. I share that concern. I really wonder whether anyone is using this at all. I did some searching and although I found reference to people using the command-line entry point, I didn't find any mention of using the Ant task. I have never tried it. I think this was something that Jess Garms did back in 2005 or so, fairly early in the Eclipse / WebLogic Workshop integration. Thanks for releasing the bounds change. Did you update map files for the I-build, or do I still need to do that?
(In reply to comment #12) > Thanks for releasing the bounds change. Did you update map files for the > I-build, or do I still need to do that? Yes, the map file is updated and ready for the next I-build
I also took advantage of this update for remove deprecation warnings (usage of preference scope's constructors instead of the new INSTANCE fields) from other apt bundles.
