Re: Jenkins Jobs of Ivy/IvyDE

[Nicolas Lalevée]

> Dropins (or "drops" as they're called in the distributions) is what IvyDE
> builds were based on all the time. I am still confounded why it worked
> before and stopped working now. Yet, reading the documentation I became
> convinced that the dropins must be unpacked in another location. So I just
> wanted to apologize for an erroneous suggestion and share some information
> in order for it to be independently confirmed. I may open a PR, but since
> you're working on this, I assumed that you could move faster than me.

Actually I am not looking into it at the present time. I’ll get into it at some 
point, if it is not fixed before. So if you think you can solve this, I’ll 
welcome your help.

On the side note, I am now an Intellij user, I only start Eclipse to build 
IvyDE. And I haven’t done Eclipse plugin development in years, so I am not 
fast. :)

> There's another issue to be resolved for local builds to work hassle-free
> -- currently, they need an environment variable BUILD_NUMBER set up by
> Jenkins.

Is it required ? This env variable is only needed when calling the jenkins 
target. In a dev environment we shouldn't call them.

I think in this mailing list we told to run some jenkins target to make easier 
the setup of the dev environment. But it as actually to call the targets which 
download and setup Eclipse. That’s why I renamed them, so we should continue to 
make the proper distinction to the tweaks for Jenkins, and the dev targets.

Nicolas

Re: Jenkins Jobs of Ivy/IvyDE

[Gintautas Grigelionis]

2017-06-26 13:54 GMT+02:00 Nicolas Lalevée :

>
> > Le 26 juin 2017 à 07:46, Gintautas Grigelionis 
> 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.
>

Sorry, I misunderstood the brief description. In my world,
"prepare-eclipse" should also download Ivy and add it to PDE.


> 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.
>

Thanks, now I get the idea.

> 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.
>

Dropins (or "drops" as they're called in the distributions) is what IvyDE
builds were based on all the time. I am still confounded why it worked
before and stopped working now. Yet, reading the documentation I became
convinced that the dropins must be unpacked in another location. So I just
wanted to apologize for an erroneous suggestion and share some information
in order for it to be independently confirmed. I may open a PR, but since
you're working on this, I assumed that you could move faster than me.
There's another issue to be resolved for local builds to work hassle-free
-- currently, they need an environment variable BUILD_NUMBER set up by
Jenkins.

Gintas


> > [1] https://wiki.eclipse.org/Equinox/p2/Getting_Started#Dropins
> >
> >
> > 2017-06-25 22:27 GMT+02:00 Nicolas Lalevée :
> >
> >>
> >>> 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:
> >>> >> failonerror="false"
> >>> />
> >>> >>> failonerror="false" />
> >>> >>> dest="${basedir}/dependencies/" />
> >>> - >>> dest="${basedir}/dependencies/" />
> >>> - >>> dest="${basedir}/dependencies/" />
> >>> - >>> dest="${basedir}/dependencies/" />
> >>> - >>> dest="${basedir}/dependencies/" />
> >>> - >>> dest="${basedir}/dependencies/" />
> >>> + >>> dest="${basedir}/dependencies/eclipse/dropins" />
> >>> + >>> dest="${basedir}/dependencies/eclipse/dropins" />
> >>> + >>> dest="${basedir}/dependencies/eclipse/dropins" />
> >>> + >>> dest="${basedir}/dependencies/eclipse/dropins" />
> >>> + >>> dest="${basedir}/dependencies/eclipse/dropins" />
> >>> >>> tofile="${basedir}/dependencies/${eclipse.download.sdk.name}" />
> >>>
> >>
> >> I don’t understand what you are suggesting. The issue at hand is
> resolving
> >> the Ivy jar. Th

Re: Jenkins Jobs of Ivy/IvyDE

[Nicolas Lalevée]

> Le 26 juin 2017 à 07:46, Gintautas Grigelionis  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 :
> 
>> 
>>> 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:
>>>> failonerror="false"
>>> />
>>>>> failonerror="false" />
>>>>> dest="${basedir}/dependencies/" />
>>> ->> dest="${basedir}/dependencies/" />
>>> ->> dest="${basedir}/dependencies/" />
>>> ->> dest="${basedir}/dependencies/" />
>>> ->> dest="${basedir}/dependencies/" />
>>> ->> dest="${basedir}/dependencies/" />
>>> +>> dest="${basedir}/dependencies/eclipse/dropins" />
>>> +>> dest="${basedir}/dependencies/eclipse/dropins" />
>>> +>> dest="${basedir}/dependencies/eclipse/dropins" />
>>> +>> dest="${basedir}/dependencies/eclipse/dropins" />
>>> +>> dest="${basedir}/dependencies/eclipse/dropins" />
>>>>> tofile="${basedir}/dependencies/${eclipse.download.sdk.name}" />
>>>
>> 
>> 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

Re: [1/5] ant-ivy git commit: set copyright to 2017

[Nicolas Lalevée]

> Le 26 juin 2017 à 08:15, Matèrne, Jan (RZF, Ref 410)  
> a écrit :
> 
> Would it be better to insert the actual year to the generation process?

It can certainly be done. There is some ruby code involved, so I guess this is 
doable.

> If I remember right Stefan had changed the site templates regarding the 
> license link (.../ instead of .../LICENSE-2.0.txt).
> Should we use that link here too?

Yep, good idea. Done.

Nicolas

> 
> cheers
> Jan
> 
> -Ursprüngliche Nachricht-
> Von: hi...@apache.org  [mailto:hi...@apache.org 
> ] 
> Gesendet: Sonntag, 25. Juni 2017 01:09
> An: notificati...@ant.apache.org 
> Betreff: [1/5] ant-ivy git commit: set copyright to 2017
> 
> 
> http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/97c24fdd/asciidoc/templates/document.html.slim
> --
> diff --git a/asciidoc/templates/document.html.slim 
> b/asciidoc/templates/document.html.slim
> index 41d344a..637affb 100644
> --- a/asciidoc/templates/document.html.slim
> +++ b/asciidoc/templates/document.html.slim
> @@ -76,7 +76,7 @@ html lang=(attr :lang, 'en' unless attr? :nolang)
>   div id="footer-message" class="footer"
> hr/
> i
> -  | Copyright © 2014 The Apache Software Foundation, Licensed 
> under the
> +  | Copyright © 2017 The Apache Software Foundation, Licensed 
> under the
>   a href="http://www.apache.org/licenses/LICENSE-2.0.txt"; Apache 
> License, Version 2.0
>   | .
> br/
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org 
> 
> For additional commands, e-mail: dev-h...@ant.apache.org 
>