> Le 26 juin 2017 à 07:46, Gintautas Grigelionis <g.grigelio...@gmail.com> a > écrit : > > If I understand the process correctly, Jenkins executes "ant > prepare-jenkins" first, which does not work locally any more, because the > property used to figure out where to get Ivy jar from is set to an empty > string. I wondered what was the reason for that change. Actually, when I > look at it again, the change is even more drastic. Previously, > "hudson-install-ivy" would depend on both "hudson-install-ivy-jar" (setting > "ivy.jar.url") and "hudson-install-ivy-release" (setting "ivy.version" if > "hudson.ivy.jar.url" was not available). In addition, "baseLocation" was > set. The new target "jenkins-install-ivy" does not make sense to me.
This is because of the change in the configuration of Jenkins Job, as I briefly explained in the first mail. Now the Ivy artifact is not downloaded via an url, there is a Jenkins plugin, a build step, which handle the copy of the artifacts. Relying on this internal copy of artifact seems more stable that relying on a http/https url. The jenkins-install-ivy target is then calling install-ivy with a path rather than an url. Now the jenkins-* targets are really dedicated to being ran on jenkins and are not suited for a local environment. That is why I renamed the targets to download and setup an eclipse, removing the jenkins- prefix: these can be used in a dev environment. If you do that: ant prepare-eclipse And do the install: ant install-ivy -Divy.jar.url=https://builds.apache.org/view/A/view/Ant/job/Ivy/lastSuccessfulBuild/artifact/build/artifact/jars/ivy.jar Then you will be able to reproduce the issue. At least I can. > In the next step, Jenkins executes "ant dist checkstyle rat" which fails > because of "missing" Eclipse plugins. That is apparently caused by dropins > being unpacked in the wrong place in the first build stage > ("prepare-jenkins"). In my first suggestion, I was obviously wrong about > what that place should be. I do recall using getting Eclipse to work > locally with an older IvyDE build.xml, but I did not document whether that > involved any extra steps. However, Eclipse is able to bootstrap itself > locally when dropins are unpacked in "dropins" directory, see Eclipse > documentation [1]. That's what the patch is for. I don’t have much experience with using dropins, so if you think this will help make the build more stable, you’re welcomed to open a PR. Nicolas > > Gintas > > [1] https://wiki.eclipse.org/Equinox/p2/Getting_Started#Dropins > > > 2017-06-25 22:27 GMT+02:00 Nicolas Lalevée <nicolas.lale...@hibnet.org>: > >> >>> I am sorry, my memory of what I was doing back in December is incorrect. >>> I guess I somehow updated >>> configuration/org.eclipse.equinox.simpleconfigurator/bundles.info or did >>> something else. >>> Luckily, there's a simpler way, the dropins should go into their own >>> special directory, which needs the following change >>> >>> --- a/build.xml >>> +++ b/build.xml >>> @@ -555,11 +555,11 @@ You have to specify the Ivy to install with one of >>> the following property: >>> <delete dir="${basedir}/dependencies/eclipse" >> failonerror="false" >>> /> >>> <delete dir="${basedir}/dependencies/${eclipse.download.sdk.name >> }" >>> failonerror="false" /> >>> <unzip src="${basedir}/dependencies/${eclipse.download.sdk.name >> }.zip" >>> dest="${basedir}/dependencies/" /> >>> - <unzip src="${basedir}/dependencies/${eclipse.download.wtp.name >> }.zip" >>> dest="${basedir}/dependencies/" /> >>> - <unzip src="${basedir}/dependencies/${eclipse.download.emf.name >> }.zip" >>> dest="${basedir}/dependencies/" /> >>> - <unzip src="${basedir}/dependencies/${eclipse.download.xsd.name >> }.zip" >>> dest="${basedir}/dependencies/" /> >>> - <unzip src="${basedir}/dependencies/${eclipse.download.gef.name >> }.zip" >>> dest="${basedir}/dependencies/" /> >>> - <unzip src="${basedir}/dependencies/${ >> eclipse.download.zest.name}.zip" >>> dest="${basedir}/dependencies/" /> >>> + <unzip src="${basedir}/dependencies/${eclipse.download.wtp.name >> }.zip" >>> dest="${basedir}/dependencies/eclipse/dropins" /> >>> + <unzip src="${basedir}/dependencies/${eclipse.download.emf.name >> }.zip" >>> dest="${basedir}/dependencies/eclipse/dropins" /> >>> + <unzip src="${basedir}/dependencies/${eclipse.download.xsd.name >> }.zip" >>> dest="${basedir}/dependencies/eclipse/dropins" /> >>> + <unzip src="${basedir}/dependencies/${eclipse.download.gef.name >> }.zip" >>> dest="${basedir}/dependencies/eclipse/dropins" /> >>> + <unzip src="${basedir}/dependencies/${ >> eclipse.download.zest.name}.zip" >>> dest="${basedir}/dependencies/eclipse/dropins" /> >>> <move file="${basedir}/dependencies/eclipse" >>> tofile="${basedir}/dependencies/${eclipse.download.sdk.name}" /> >>> </target> >> >> I don’t understand what you are suggesting. The issue at hand is resolving >> the Ivy jar. The suggested patch is about installing eclipse plugins in >> dropins. But the build is still not finding the ivy plugin. >> >>> I don't understand why "jenkins-prepare" (neé "hudson-prepare") would >> skip >>> "download-ivy" (because "jenkins-install-ivy" sets ivy.jar.url to "" >> rather >>> than ${hudson.ivy.jar.url}) and fail? >> >> Again, sorry, but I don’t understand what you are talking about. Are you >> seing the same error as the one Jenkins is showing ? The error is occurring >> with the eclipse build started, way later. >> >> Nicolas >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
