Community
Participate
Working Groups
Apache released 1.9.7 and they are working on Release Ant 1.9.8 https://github.com/apache/ant/blob/master/WHATSNEW Based on the timing and content of next Apache Ant release, Eclipse Ant version upgrade will be decided.
It would be good to release 1.9.7 as it has some important fixes for Java 9. The next release will be 1.10 and there is no ETA AFAIK so it would be best to not wait for it. Additionally, we should not do such updates in later milestones. Is there anything needed to help with this work?
Let's target M5.
Shouldn't we wait for 1.9.8 ? https://github.com/apache/ant/blob/1.9.x/WHATSNEW It has also - The ant.java.version property will now hold the value "9" rather than "1.9" if running on Java 9.
(In reply to Sarika Sinha from comment #3) > Shouldn't we wait for 1.9.8 ? It depends how long. Is there an ETA?
(In reply to Dani Megert from comment #4) > (In reply to Sarika Sinha from comment #3) > > Shouldn't we wait for 1.9.8 ? > > It depends how long. Is there an ETA? I am hoping it to be clear by this month end and I plan to start working on this in Jan so we can take a call at that time.
(In reply to Sarika Sinha from comment #5) > (In reply to Dani Megert from comment #4) > > (In reply to Sarika Sinha from comment #3) > > > Shouldn't we wait for 1.9.8 ? > > > > It depends how long. Is there an ETA? > > I am hoping it to be clear by this month end and I plan to start working on > this in Jan so we can take a call at that time. So 1.9.8 and 1.10.0 were released at the same time. I would vote for going to 1.10 directly now.
(In reply to Alexander Kurtakov from comment #6) > (In reply to Sarika Sinha from comment #5) > > (In reply to Dani Megert from comment #4) > > > (In reply to Sarika Sinha from comment #3) > > > > Shouldn't we wait for 1.9.8 ? > > > > > > It depends how long. Is there an ETA? > > > > I am hoping it to be clear by this month end and I plan to start working on > > this in Jan so we can take a call at that time. > > So 1.9.8 and 1.10.0 were released at the same time. I would vote for going > to 1.10 directly now. -1 until the impact is understood. AFAIK this will break everyone who wants to use Ant to build with Java < 1.8. Sarika, please provide details about the impact going to 1.10.0.
*** Bug 509800 has been marked as a duplicate of this bug. ***
I think it should be ok to move to 1.10 after the changes we did for Bug 495617. So by default, Ant Home will be 1.10 and will require Java 1.8, but if user changes Ant home, it can use the earlier Java versions. I will be working on this and will update on any hurdles/changes/success.
HURDLE - some basic any tests to build are failing with 1.10.0 Same works well with 1.9.8 So we have two ways, we can go and adopt 1.9.8 now and then work to analyze the failures and later move to 1.10.x
(In reply to Sarika Sinha from comment #10) > HURDLE - some basic any tests to build are failing with 1.10.0 > > Same works well with 1.9.8 > > So we have two ways, we can go and adopt 1.9.8 now and then work to analyze > the failures and later move to 1.10.x Hi, is there a patch somewhere that I can try? Fedora Linux moved to Ant 1.10 already and as a downstream consumer, I'd like to make sure our Eclipse packages play nicely with the version of Ant that we ship.
Will be adding it soon (probably tomorrow), right now I am having some test failure of missing stack frames when executed in separate JRE.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60582 Ant 1.9.8 and 1.10.0 both had made org.apache.tools.ant.types.Path.systemClasspath as final which Eclipse Ant was setting. I had changed org.eclipse.ant.internal.ui.model.AntDefiningTaskNode to set the path by directly setting the system path, but now they have made the property non final again for 1.9.9 and 1.10.1 which might be out in few weeks it seems. Right now I am having only 1 test failure in Ant UI Test case org.eclipse.ant.tests.ui.debug.SteppingTests.testStepIntoAntCallSepVM() Where we are observing missing stack frames. The 2nd stack frame is missing.
The difference in messages received : Working case - message: suspendedbreakpoint,C:\Eclipse\Workspace\runtime-New_configurationTracepoint1\TracepointTest\debugAntCall.xml,5 message: stack,default,antcall,C:\Eclipse\Workspace\runtime-New_configurationTracepoint1\TracepointTest\debugAntCall.xml,5, message: suspendedstep message: stack,pre-call,echo,C:\Eclipse\Workspace\runtime-New_configurationTracepoint1\TracepointTest\debugAntCall.xml,16,call,,C:\Eclipse\Workspace\runtime-New_configurationTracepoint1\TracepointTest\debugAntCall.xml,10,default,antcall,C:\Eclipse\Workspace\runtime-New_configurationTracepoint1\TracepointTest\debugAntCall.xml,5, Failing case - message: suspendedbreakpoint,C:\Eclipse\Workspace\ant-junit-workspace\Ant UI Tests\buildfiles\debugAntCall.xml,5 message: stack,default,antcall,C:\Eclipse\Workspace\ant-junit-workspace\Ant UI Tests\buildfiles\debugAntCall.xml,5, message: suspendedstep message: stack,pre-call,echo,C:\Eclipse\Workspace\ant-junit-workspace\Ant UI Tests\buildfiles\debugAntCall.xml,16,default,antcall,C:\Eclipse\Workspace\ant-junit-workspace\Ant UI Tests\buildfiles\debugAntCall.xml,5, So the difference in the last message where below part is missing - call,,C:\Eclipse\Workspace\runtime-New_configurationTracepoint1\TracepointTest\debugAntCall.xml
(In reply to Sarika Sinha from comment #13) > https://bz.apache.org/bugzilla/show_bug.cgi?id=60582 > > Ant 1.9.8 and 1.10.0 both had made > org.apache.tools.ant.types.Path.systemClasspath as final which Eclipse Ant > was setting. > I had changed org.eclipse.ant.internal.ui.model.AntDefiningTaskNode to set > the path by directly setting the system path, but now they have made the > property non final again for 1.9.9 and 1.10.1 which might be out in few > weeks it seems. > That's good to know -- I had to do some nasty reflection in Fedora to work around this change.
Investigation - - Debugging Ant file while using Run in Same JRE as Workspace org.apache.tools.ant.Project.executeTargets(Vector<String>) is invoked and it works well - Debugging Ant file while using Separate JRE, AntLaunchDelegate is used which uses VMRunner to run it Still not able to figure out why it is failing for 1.10 when separate VM is used which doesn't even use Ant execute. @Mike, Any suggestion ?
Moving to M6 as issues are not yet resolved.
(In reply to Sarika Sinha from comment #16) > Investigation - > - Debugging Ant file while using Run in Same JRE as Workspace > org.apache.tools.ant.Project.executeTargets(Vector<String>) is invoked and > it works well > > - Debugging Ant file while using Separate JRE, AntLaunchDelegate is used > which uses VMRunner to run it > > Still not able to figure out why it is failing for 1.10 when separate VM is > used which doesn't even use Ant execute. > > @Mike, > Any suggestion ? Nothing is immediately coming to mind - but check in the *Helper classes, as your trace reads like a callback is no longer be run (perhaps another regression / intentional change from Ant?)
https://bz.apache.org/bugzilla/show_bug.cgi?id=60582 Resolved in 1.9.9 and 1.10.1
Have created CQs for 1.10.1 Thanks Mike for giving the pointers to debug. Finally found the problem and now all the tests pass with 1.10.1
Hi, Any chance I can see/try out the patch?
New Gerrit change created: https://git.eclipse.org/r/92058
New Gerrit change created: https://git.eclipse.org/r/92057
Moving to M7 as need the maven central setup done.
Comments in https://git.eclipse.org/r/#/c/92058/ hide an important caveat: > it appears that the maven central artifacts for this (org.apache.ant:ant) is > missing some things that the previous ant bundle we shipped did contain. Changing the scope in the next version of a published Orbit bundle is a no-go. If there's no Maven Central artifact we can refer to in an Orbit Recipe, then we should simply use the established process and put the bits we need in CVS.
Gerrit change https://git.eclipse.org/r/92058 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=e2c7c60d60771931a087b26584d12004acc71fe0
New Gerrit change created: https://git.eclipse.org/r/94092
Gerrit change https://git.eclipse.org/r/94092 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=c745c4ed4039e42b05bae5616074bba1eb17d854
New Gerrit change created: https://git.eclipse.org/r/94352
Gerrit change https://git.eclipse.org/r/94352 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=ee7968e5107df15fb594f9fcc0c44f0c2218bbb3
Getting compilation errors http://download.eclipse.org/eclipse/downloads/drops4/I20170405-0200/compilelogs/plugins/org.eclipse.ant.core_3.5.0.qualifier/lib_antsupportlib.jar.html#ERRORS
New Gerrit change created: https://git.eclipse.org/r/94427
Gerrit change https://git.eclipse.org/r/94427 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=91b8ca13feaf242fe380babf1bd75427be8e7f9a
(In reply to Eclipse Genie from comment #33) > Gerrit change https://git.eclipse.org/r/94427 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=91b8ca13feaf242fe380babf1bd75427be8e7f9a > This reverted the update to Ant 1.10.1.
New Gerrit change created: https://git.eclipse.org/r/94526
New Gerrit change created: https://git.eclipse.org/r/94527
New Gerrit change created: https://git.eclipse.org/r/94673
Gerrit change https://git.eclipse.org/r/94673 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=482b1ea1ad98116b1977b5da83bfe943cdb0e7ca
Sarika, re: your last comment on https://git.eclipse.org/r/94673. I might be wrong. From looking at the code it looked like the launching code would work with the jar file names including the version number. Have you tested that this does not work?
(In reply to Gunnar Wagenknecht from comment #39) Yes, I tried out. It doesn't work.
Created attachment 267858 [details] screenshot of Ant classpath Screenshot of Ant classpath working out-of-the-box with the version suffix in jars.
(In reply to Sarika Sinha from comment #40) > (In reply to Gunnar Wagenknecht from comment #39) > Yes, I tried out. It doesn't work. Please have a look at the screenshot I attached. It uses org.eclipse.ant.core.AntCorePreferences.getDefaultAntHomeEntries() for computing the Ant classpath. Is the launching code using something else? What error do you get?
New Gerrit change created: https://git.eclipse.org/r/95437
(In reply to Gunnar Wagenknecht from comment #42) > (In reply to Sarika Sinha from comment #40) > > (In reply to Gunnar Wagenknecht from comment #39) > > Yes, I tried out. It doesn't work. > > Please have a look at the screenshot I attached. It uses > org.eclipse.ant.core.AntCorePreferences.getDefaultAntHomeEntries() for > computing the Ant classpath. Is the launching code using something else? > What error do you get? I tried tweaking the Ant code a bit and the tests, I think it should be ok to use even with suffixes in the jar name. Can we have the I build for Orbit so that we can actually test on the build early as we are nearing M7 deadline.
I've promoted I20170424150726 and it should be visible on the downloads page. Build Page : http://download.eclipse.org/tools/orbit/downloads/drops/I20170424150726/ p2 Repo : http://download.eclipse.org/tools/orbit/downloads/drops/I20170424150726/repository
Gerrit change https://git.eclipse.org/r/95437 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=1c943b267180d5877ed20f0839770a066962276c
New Gerrit change created: https://git.eclipse.org/r/95639
(In reply to Eclipse Genie from comment #47) > New Gerrit change created: https://git.eclipse.org/r/95639 aggregator changes in eclipse-sdk-prereqs
Gerrit change https://git.eclipse.org/r/95639 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=749b0fc213a7240ad67df324eccc1e6e7159d0ac
New Gerrit change created: https://git.eclipse.org/r/95640
Gerrit change https://git.eclipse.org/r/95640 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=93dedb278a8826a1d320ab51499412303dca22cc
Build failed with https://hudson.eclipse.org/releng/job/I-build/325/console
The JAR names in the org.apache.ant bundle should keep the original names. Especially /org.apache.ant/lib/ant.jar must keep that exact name, since this JAR is referenced from build.properties files all over the world like this: jars.extra.classpath = platform:/plugin/org.apache.ant/lib/ant.jar http://help.eclipse.org/neon/topic/org.eclipse.pde.doc.user/reference/pde_feature_generating_build.htm also includes this as an example.
Reason for build failure : eclipse.platform.releng.aggregator/eclipse.platform.ua/org.eclipse.help.base depends on ant.jar Now the name of jar is changing with each version like current one is ant-1.10.1.jar
Roland, Gunnar, what is the estimate for getting ant in orbit without versions in the jar names?
New Gerrit change created: https://git.eclipse.org/r/95666
(In reply to Alexander Kurtakov from comment #55) > Roland, Gunnar, what is the estimate for getting ant in orbit without > versions in the jar names? Can this please be fixed asap. We need to get Ant into M7 and Sarika is away starting next week. Thanks!
(In reply to Eclipse Genie from comment #56) > New Gerrit change created: https://git.eclipse.org/r/95666 Reverted the Platform Ant changes till we have the jars.
I'll look into this (change has to happen on the ebr-maven-plugin side, but should be easy to make). Gunnar will have to push my change in and promote the plugin to the repo.eclipse instance.
I've proposed https://github.com/eclipse/ebr/pull/18 . On the orbit-recipes side, we just need to enable the newly provided property, which I can do once the change is in.
(In reply to Roland Grunberg from comment #60) > I've proposed https://github.com/eclipse/ebr/pull/18 . On the orbit-recipes > side, we just need to enable the newly provided property, which I can do > once the change is in. Thanks Roland! I kicked https://hudson.eclipse.org/ebr/job/ebr-maven-plugins/199/ to publish a new build of the EBR plug-in. You can start preparing the Orbit recipe in parallel.
New Gerrit change created: https://git.eclipse.org/r/95714
Gerrit change https://git.eclipse.org/r/95714 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=8c7045278d1c854c3c9d1219d48f1e5cad246ce1
Can you try out I20170425174753 ? Build Page : http://download.eclipse.org/tools/orbit/downloads/drops/I20170425174753/ p2 Repo : http://download.eclipse.org/tools/orbit/downloads/drops/I20170425174753/repository
(In reply to Roland Grunberg from comment #64) > Can you try out I20170425174753 ? Now the jar names are fine, but still platform:/plugins/org.apache.ant/ant.jar is not resolved. We used to have it as extracted folder as well. So we might need that. I found something related mention in https://wiki.eclipse.org/Orbit/Adding_Bundles_to_Orbit#build.properties_entries_and_.classpath_file Also, we need to add 2 folders bin and etc to the output jar. I could not found any entry in wiki how to put the dependency in such cases. Should I add those files from bin and src distribution from org.apache.ant to main/resources folder in recipe ? Please suggest.
Adding additional(In reply to Sarika Sinha from comment #65) > Now the jar names are fine, but still > platform:/plugins/org.apache.ant/ant.jar is not resolved. We used to have it > as extracted folder as well. This requires setting the Eclipse-BundleShape header. http://eclipsesource.com/blogs/2009/01/20/tip-eclipse-bundleshape/ I'll propose a review. > Also, we need to add 2 folders bin and etc to the output jar. Can you precisely define which folders from which jars needs to go into which directory? We do have the possibility of adding additional resources. We just need clear instructions. Thanks! :)
New Gerrit change created: https://git.eclipse.org/r/95810
New Gerrit change created: https://git.eclipse.org/r/95811
So Gunnar has taken care of bundle-shape and I've proposed https://git.eclipse.org/r/95811/. I wasn't able to find any artifact that contained the 'etc', 'bin' folders along with their files on maven central so the other option is to manully include them in 'resources' and they'll end up in the bundle.
New Gerrit change created: https://git.eclipse.org/r/95816
Gerrit change https://git.eclipse.org/r/95810 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=cd601662e3f44ce9c588b7a6e3c9d14adeabf131
Gerrit change https://git.eclipse.org/r/95811 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=16f61fb6135f45cfee37c9ec1de5ab81b3293556
Gerrit change https://git.eclipse.org/r/95816 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=e8e2a0557a4106dac7625a2d9ce7774fd5bba955
I20170426205152 Build Page : http://download.eclipse.org/tools/orbit/downloads/drops/I20170426205152/ p2 Repository : http://download.eclipse.org/tools/orbit/downloads/drops/I20170426205152/repository 'bin' and 'etc' folders are now within the jar, and it has EclipseBundleShape: dir .
Going through the apache.ant jar 1.10.1.v20170426-1603 , we see following differences which needs to be addressed before we release to SDK builds - > about_files We need to have all the original licenses > Bundle-ClassPath: ., [...] We now have a new entry of ".", This does not harm but can be removed as well. > Eclipse-SourceReferences: scm:cvs:pserver:dev.eclipse.org:/cvsroot/too ls:org.eclipse.orbit/org.apache.ant;tag=v201510161327 This is missing in the jar. Users will lose the way to import the plugins from repository but with ebr may be that's the way to go. > Export-Package: bin;version="1.10.1",etc;version="1.10.1",etc.checksty le;version="1.10.1",images;version="1.10.1",lib; We should not have folders exported specifically like bin,etc and lib. May be this as a result of Bundle Classpath entry of ".". This export addition may interfere with other exported packages. > Bundle name needs to Apache ant , currently it is Apache Ant Core > License - We need some more licenses - 1. apache source jar/LICENSE and apache source jar/NOTICE to be copied to /about_files folder 2. I am attaching gerrit to add DOM-LICENSE and SAX-LICENSE to be added to about_files folder
New Gerrit change created: https://git.eclipse.org/r/95883
New Gerrit change created: https://git.eclipse.org/r/95885
(In reply to Sarika Sinha from comment #75) > > about_files > We need to have all the original licenses Is this all covered in the review you submitted? > > Bundle-ClassPath: ., [...] > We now have a new entry of ".", This does not harm but can be removed as > well. I'm reluctant to take this out. It would require a change in the EBR Maven plug-in to support this. > > Eclipse-SourceReferences: scm:cvs:pserver:dev.eclipse.org:/cvsroot/too > ls:org.eclipse.orbit/org.apache.ant;tag=v201510161327 > > This is missing in the jar. Users will lose the way to import the plugins > from repository but with ebr may be that's the way to go. This is currently not enabled. However, I think it is possible to add this with Tycho. Can you open a bug to get it onto the backlog? I don't think it's critical in this case, though. > > Export-Package: bin;version="1.10.1",etc;version="1.10.1",etc.checksty > le;version="1.10.1",images;version="1.10.1",lib; > > We should not have folders exported specifically like bin,etc and lib. May > be this as a result of Bundle Classpath entry of ".". This export addition > may interfere with other exported packages. https://git.eclipse.org/r/95885 > > Bundle name needs to Apache ant , currently it is Apache Ant Core It's in the bundle.properties. Can you submit a review?
(In reply to Gunnar Wagenknecht from comment #78) > (In reply to Sarika Sinha from comment #75) > > > about_files > > We need to have all the original licenses > > Is this all covered in the review you submitted? No, I have added from old project only. > > > > Bundle-ClassPath: ., [...] > > We now have a new entry of ".", This does not harm but can be removed as > > well. > > I'm reluctant to take this out. It would require a change in the EBR Maven > plug-in to support this. This is ok. > > > > Eclipse-SourceReferences: scm:cvs:pserver:dev.eclipse.org:/cvsroot/too > > ls:org.eclipse.orbit/org.apache.ant;tag=v201510161327 > > > > This is missing in the jar. Users will lose the way to import the plugins > > from repository but with ebr may be that's the way to go. > > This is currently not enabled. However, I think it is possible to add this > with Tycho. Can you open a bug to get it onto the backlog? I don't think > it's critical in this case, though. Yes, I will create it. > > > > Export-Package: bin;version="1.10.1",etc;version="1.10.1",etc.checksty > > le;version="1.10.1",images;version="1.10.1",lib; > > > > We should not have folders exported specifically like bin,etc and lib. May > > be this as a result of Bundle Classpath entry of ".". This export addition > > may interfere with other exported packages. > > https://git.eclipse.org/r/95885 > > > > Bundle name needs to Apache ant , currently it is Apache Ant Core > > It's in the bundle.properties. Can you submit a review? Done in the gerrit.
Gerrit change https://git.eclipse.org/r/95883 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=c3e4aa3640002c37a88e865bd5f4f3b6787d95dc
Gerrit change https://git.eclipse.org/r/95885 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=e01c5b2aa3eecedf645788d89f3b3b0f778f5fc0
New Gerrit change created: https://git.eclipse.org/r/95938
Gerrit change https://git.eclipse.org/r/95938 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=00931c6d7ef8e8b2e49d023200d6ffc33dc6352e
I20170427202855 Build Page : http://download.eclipse.org/tools/orbit/downloads/drops/I20170427202855/ p2 Repository : http://download.eclipse.org/tools/orbit/downloads/drops/I20170427202855/repository
(In reply to Roland Grunberg from comment #84) > I20170427202855 > Build Page : > http://download.eclipse.org/tools/orbit/downloads/drops/I20170427202855/ > p2 Repository : > http://download.eclipse.org/tools/orbit/downloads/drops/I20170427202855/ > repository Things mentioned before looks fine, Thanks!! But there are some failure in Ant tests due to inclusion of "." in build classpath. I am working on it.
(In reply to Sarika Sinha from comment #85) > (In reply to Roland Grunberg from comment #84) > > I20170427202855 > > Build Page : > > http://download.eclipse.org/tools/orbit/downloads/drops/I20170427202855/ > > p2 Repository : > > http://download.eclipse.org/tools/orbit/downloads/drops/I20170427202855/ > > repository > > Things mentioned before looks fine, Thanks!! > > But there are some failure in Ant tests due to inclusion of "." in build > classpath. I am working on it. If it's gonna be fix in the tests can we get the rest in to verify everything else is fine?
New Gerrit change created: https://git.eclipse.org/r/95988
(In reply to Eclipse Genie from comment #87) > New Gerrit change created: https://git.eclipse.org/r/95988 Sravan, I have updated the prereqs, Please release. I I have released the test changes also. http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=8dea80f0b3ac6ba1f86b54d59ab2f122b2094728
New Gerrit change created: https://git.eclipse.org/r/95990
Gerrit change https://git.eclipse.org/r/95990 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=99e78c5d3234c2bc86b452b42b50189920e43703
With I20170428-0830 we now have the first build with Ant 1.10.1 in it. It looks like some APIs got removed: http://download.eclipse.org/eclipse/downloads/drops4/I20170428-0830/apitools/freeze_report.html For example, why is org.apache.tools.ant.taskdefs.compilers.AptCompilerAdapter gone? Is this expected? Is this documented?
(In reply to Dani Megert from comment #91) > With I20170428-0830 we now have the first build with Ant 1.10.1 in it. It > looks like some APIs got removed: > http://download.eclipse.org/eclipse/downloads/drops4/I20170428-0830/apitools/freeze_report.html > > For example, why is > org.apache.tools.ant.taskdefs.compilers.AptCompilerAdapter gone? Is this > expected? Is this documented? OK, I found this in http://ant.apache.org/antnews.html: " Ant 1.10.1 contains a superset of 1.9.9 - with the exception of a few tasks and features that no longer work with Java8 anyway (like the apt task). " ==> This needs to be documented in our migration guide.
Created attachment 268073 [details] WHATSNEW for Ant 1.10.1 The <apt> change may be the most significant change (I do not know) but FYI here is the "whatsnew" file from the Ant 1.10.1 binary distribution. Here are some other interesting highlights: Fixed bugs: ----------- [note, fixed in 1.10.1 ... I just thought it interesting that Eclispe was mentioned!] * Ant 1.10.0 made Path#systemClasspath final which broke the Eclipse integration. Bugzilla Report 60582 Other changes: -------------- [I mention this one since, in theory, the build scripts could be made more portable. AFAIK we still use linux command to compress the metadata files to xz] * new tasks <xz> and <unxz> and resource <xzresource> for XZ compression. Also the compression attribute of <tar>/<untar> now accepts "xz" as valid value. The tasks and type are contained in the new ant-xz.jar and require the library XZ for Java to be on the CLASSPATH. Bugzilla Report 60350 Changes from Ant 1.9.7 TO Ant 1.10.0 ==================================== Changes that could break older environments: ------------------------------------------- * Ant 1.10.x requires Java8 or newer at compile or build time. The 1.9.x series wil stay compatible with Java5. [They didn't say what is required at runtime?] * The <apt> task has been removed since apt itself has been removed with Java8. * <fileset>/<zipfileset>/<tarfileset> exhibited undefined behavior when both the dir and file attribute have been used on the same instance. This will now cause the build to fail. Bugzilla Report 59402 * <native2ascii> will default to the builtin implementation on Java8 as well (sun isn't available for Java9+ anyway). * The ant.java.version property will now hold the value "9" rather than "1.9" if running on Java 9. ... and many many more.
(In reply to David Williams from comment #93) > > Changes that could break older environments: > ------------------------------------------- > > * Ant 1.10.x requires Java8 or newer at compile or build time. > The 1.9.x series wil stay compatible with Java5. > [They didn't say what is required at runtime?] > Ah, they were more explicit on their download page: "The Apache Ant team currently maintains two lines of development. The 1.9.x releases require Java5 at runtime *and 1.10.x requires Java8 at runtime*. Both lines are based off of Ant 1.9.7 and the 1.9.x releases are mostly bug fix releases while additional new features are developed for 1.10.x. We recommend using 1.10.x unless you are required to use versions of Java prior to Java8 during the build process." [emphasis mine] Apologies if already mentioned. 90 comments are too many for me to skim read! :)
Looking at 2 ant.core and 3 ant.ui test failures http://download.eclipse.org/eclipse/downloads/drops4/I20170501-2000/testResults.php
(In reply to Sarika Sinha from comment #95) > Looking at 2 ant.core and 3 ant.ui test failures > http://download.eclipse.org/eclipse/downloads/drops4/I20170501-2000/ > testResults.php In my local I get 2 test failures in core and 1 in ui > not 3 in ui like the build. Stack tests should not have failed in build also. For AntHome -> In preferences we have proper ant home but while running ant command with diagnostics, The ant Home what we get is Eclipse home and not Eclipse home/plugins/or.apache.ant diretory
All tests pass with the released changes http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=8a150c01c2f8f742b758240f78a3251cb0933fbe
(In reply to Sarika Sinha from comment #97) > All tests pass with the released changes Nope, only the Core tests are good now. Two UI tests still fail: http://download.eclipse.org/eclipse/downloads/drops4/I20170502-2000/testresults/html/org.eclipse.ant.tests.ui_ep47I-unit-cen64-gtk2_linux.gtk.x86_64_8.0.html
(In reply to Dani Megert from comment #98) > (In reply to Sarika Sinha from comment #97) > > All tests pass with the released changes > > Nope, only the Core tests are good now. Two UI tests still fail: > http://download.eclipse.org/eclipse/downloads/drops4/I20170502-2000/ > testresults/html/org.eclipse.ant.tests.ui_ep47I-unit-cen64-gtk2_linux.gtk. > x86_64_8.0.html These are not reproducible in local, neither today nor yesterday. I was having this problem before as mentioned in Comment#20 but the changes in InternalAntRunner for version compare resolved the problem. Changes are there in master.
I am able to reproduce it now in a new workspace, the problem is that I released the changes in org.eclipse.ant.internal.launching.remote.InternalAntRunner, but that is not enough we also need to release remote.jar for the build to pick up.
New Gerrit change created: https://git.eclipse.org/r/96304
(In reply to Sarika Sinha from comment #75) > > Export-Package: bin;version="1.10.1",etc;version="1.10.1",etc.checksty > le;version="1.10.1",images;version="1.10.1",lib; > > We should not have folders exported specifically like bin,etc and lib. In org.apache.ant_1.10.1.v20170427-1805, I still see this: Export-Package: etc.checkstyle;version="1.10.1",images;version=[..] According to http://bnd.bndtools.org/chapters/820-instructions.html#selector , the rules in the bnd file would better all end in '.*'. Gerrit follows. @Gunnar: I think the widespread ... *.internal*;x-internal:=true;version="${package-version}", \ *.impl*;x-internal:=true;version="${package-version}", \ ... in EBR .bnd files should also be changed to use a terminating '.*' instead of '*'. The current form would mark packages *.internalization and *.implore as internal.
(In reply to Markus Keller from comment #102) > According to http://bnd.bndtools.org/chapters/820-instructions.html#selector > , the rules in the bnd file would better all end in '.*'. Gerrit follows. Good catch. Thanks! > @Gunnar: I think the widespread ... > > *.internal*;x-internal:=true;version="${package-version}", \ > *.impl*;x-internal:=true;version="${package-version}", \ > > ... in EBR .bnd files should also be changed to use a terminating '.*' > instead of '*'. The current form would mark packages *.internalization and > *.implore as internal. Agreed. Can you include it in the Gerrit? BTW, I also went ahead an implemented a way to exclude the '.' from the bundle classpath. Do you still need this?
New Gerrit change created: https://git.eclipse.org/r/96327
Gerrit change https://git.eclipse.org/r/96327 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=a2848d5c60d76ebb7953669f2447a17b47b1d96f
(In reply to Eclipse Genie from comment #101) > New Gerrit change created: https://git.eclipse.org/r/96304 I've moved this over to bug 515929, which should have included the updated remote.jar as well. (In reply to Gunnar Wagenknecht from comment #103) > > use a terminating '.*' instead of '*'. > > Agreed. Can you include it in the Gerrit? I've filed bug 516125 to update the mvn ebr:create-recipe task first. > BTW, I also went ahead an implemented a way to exclude the '.' from the > bundle classpath. Do you still need this? Yes, that would still be better. In the current Orbit Ant bundle, there's nothing interesting at the top level that should be on the classpath, and excluding the '.' would also mean we could drop the many exclude rules for Export-Package.
@Gunnar, let us know if you are removing "." from classpath as eclipse Ant code will have to react to it.
New Gerrit change created: https://git.eclipse.org/r/96371
New Gerrit change created: https://git.eclipse.org/r/96372
(In reply to Sarika Sinha from comment #107) > @Gunnar, > let us know if you are removing "." from classpath as eclipse Ant code will > have to react to it. Please follow https://git.eclipse.org/r/96372. Let me know if you want it included.
(In reply to Gunnar Wagenknecht from comment #110) > (In reply to Sarika Sinha from comment #107) > > @Gunnar, > > let us know if you are removing "." from classpath as eclipse Ant code will > > have to react to it. > > Please follow https://git.eclipse.org/r/96372. Let me know if you want it > included. Yes, I think we should do that, but we will consume it after M7 when Sarika is back from vacation.
Gerrit change https://git.eclipse.org/r/96371 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=7f55dbaf91f04075d888892600ca2c8f6c5a0613
Gerrit change https://git.eclipse.org/r/96372 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=110cb1934d79f10e625656d2c1a984306906bc9e
I20170508-0800 already consumed org.apache.ant_1.10.1.v20170504-0840 via bug 506953. (In reply to Sarika Sinha from comment #107) > let us know if you are removing "." from classpath as eclipse Ant code will > have to react to it. After comment 97, org.eclipse.ant.core.AntCorePreferences#getDefaultAntHome() had an unsafe workaround for the "." entry in the classpath. It could fail if entries.length == 1 here: if (entries.length > 0) { URL antjar = entries[1].getEntryURL(); // first entry is . Fixed that with http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=0520eeee43a1ae7d13d56fce514b0ea3317cf675 I didn't see anything else that would require more updates in the Eclipse Ant support. There were no test failures, since entries[1] also worked without "." on the classpath. Marking this bug as fixed.
