You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2011/10/28 22:07:12 UTC

Jenkins builds - various

I have been trying to switch the builds to the Apache named artifacts 
... but ...

== Failing to pick up jena-top:

e.g. jena-iri
(currently, I've remove the "relative POM" link)

This may be clock drift but I've tried dropping the obvious wrong slave 
(windows1)

== Warning in Jenkins configuration of nightly builds.

If I make any change to the configuration of a nightly build, a warning 
is given:


"""
Do you really mean "every minute" when you say "* */12 * * *"? Perhaps 
you meant "0 */12 * * *"
"""

under the "Schedule" box.

Does this need fixing?

== Upstream projects

The "upstream projects" seems inconsistent - I don't always see the 
right dependencies as upstream projects.

This may be a change over problem but it may be deeper.

	Andy

Re: Jenkins builds - various

Posted by Paolo Castagna <ca...@googlemail.com>.
On 29 October 2011 09:45, Andy Seaborne <an...@apache.org> wrote:
>
>>> == Upstream projects
>>>
>>> The "upstream projects" seems inconsistent - I don't always see the
>>> right dependencies as upstream projects.
>>>
>>> This may be a change over problem but it may be deeper.
>>
>> Having two pom.xml files per projects is unusual and Jenkins or some of
>> the plugins Jenkins use might be confused.
>
> I don't understand this point.  We have one POM file per Jenkins job; I'm
> trying to swap in the org.apache.jena:jena-* artifacts.

There are two pom.xml files in each "module": pom.xml (old) and pom2.xml (new).

It's true that each Jenkins job is configured to point and use just
one of those.
However, I am not sure that when a Jenkins job is configured to use pom2.xml
the presence of the other pom.xml does not cause unexpected problems.
Probably, it doesn't matter, but I have not much experience with
multiple pom.xml
files per "module".

Usually projects have just one pom.xml per "module". Jenkins might have been
tested more with projects/modules with just one pom.xml file.

Paolo

>
>        Andy
>>
>> Paolo
>>
>>>
>>>     Andy
>
>

Re: Jenkins builds - various

Posted by Andy Seaborne <an...@apache.org>.
On 29/10/11 16:49, Paolo Castagna wrote:
> Hi Andy
>
> Just an hypothesis to explain these problems.
>
> The machines used by Jenkins have a Maven repository used to cache
> artifacts
> including pom.xml files. Maybe, for some reason, one or more pom.xml
> files in
> the Maven cache on the machines used by Jenkins have not been updated.
>
> Feel free to ignore Jenkins and just make all the changes you want to make,
> I'll then look at what's going on with Jenkins and fix the problems.
> Don't waste time with it, if you don't want to.
>
> Having two pom.xml files double the amount of testing, having some projects
> using pom.xml (old) and pom2.xml (new) and other use pom.xml (new) and
> pom1.xml (old), just increase the probability of making mistakes.
>
> Paolo

Unjamming Jena_IRI seems to have fixed the development/install builds 
(but I don't know why).  We'll see if the overnight snapshot builds get 
built.

	Andy

Re: Jenkins builds - various

Posted by Paolo Castagna <ca...@googlemail.com>.
Andy Seaborne wrote:
> I may have "fixed" the build for "Jena IRI".
> 
> Having created a temporary job that worked, I deleted the Jenkins job 
> completely and created a new one.
> 
> Otherwise it was seeing old files (specifically, a POM with a relative 
> parent; also I had one instance of it reporting a parse error in the 
> parent POM chain ... but I hadn't checked anything in.
> 
> The error occurs elsewhere (e.g. Jena_Core) but I've run out of energy 
> to fix that, then the next one and the next one, ....
> 
> Deleting the workspace of a job does not fix the problem, nor does a 
> clean checkout.
> 
> Slave machine "windows1" looks to be a bad machine to get for a job. But 
> it seems to be the machine you get if you don't restrict the job, 
> possibly it's lightly because it doesn't work very well but I can't 
> gather concrete evidence.
> 
> I'm setting jobs to "ubuntu"
> 
> Sorry about the noise on jena-commits ...

Hi Andy

Just an hypothesis to explain these problems.

The machines used by Jenkins have a Maven repository used to cache artifacts
including pom.xml files. Maybe, for some reason, one or more pom.xml files in
the Maven cache on the machines used by Jenkins have not been updated.

Feel free to ignore Jenkins and just make all the changes you want to make,
I'll then look at what's going on with Jenkins and fix the problems.
Don't waste time with it, if you don't want to.

Having two pom.xml files double the amount of testing, having some projects
using pom.xml (old) and pom2.xml (new) and other use pom.xml (new) and
pom1.xml (old), just increase the probability of making mistakes.

Paolo

> 
>     Andy


Re: Jenkins builds - various

Posted by Andy Seaborne <an...@apache.org>.
I may have "fixed" the build for "Jena IRI".

Having created a temporary job that worked, I deleted the Jenkins job 
completely and created a new one.

Otherwise it was seeing old files (specifically, a POM with a relative 
parent; also I had one instance of it reporting a parse error in the 
parent POM chain ... but I hadn't checked anything in.

The error occurs elsewhere (e.g. Jena_Core) but I've run out of energy 
to fix that, then the next one and the next one, ....

Deleting the workspace of a job does not fix the problem, nor does a 
clean checkout.

Slave machine "windows1" looks to be a bad machine to get for a job. 
But it seems to be the machine you get if you don't restrict the job, 
possibly it's lightly because it doesn't work very well but I can't 
gather concrete evidence.

I'm setting jobs to "ubuntu"

Sorry about the noise on jena-commits ...

	Andy

Re: Jenkins builds - various

Posted by Andy Seaborne <an...@apache.org>.
>> == Upstream projects
>>
>> The "upstream projects" seems inconsistent - I don't always see the
>> right dependencies as upstream projects.
>>
>> This may be a change over problem but it may be deeper.
>
> Having two pom.xml files per projects is unusual and Jenkins or some of
> the plugins Jenkins use might be confused.

I don't understand this point.  We have one POM file per Jenkins job; 
I'm trying to swap in the org.apache.jena:jena-* artifacts.

	Andy
>
> Paolo
>
>>
>>      Andy


Re: Jenkins builds - various

Posted by Paolo Castagna <ca...@googlemail.com>.
Hi Andy

Andy Seaborne wrote:
> I have been trying to switch the builds to the Apache named artifacts
> ... but ...
> 
> == Failing to pick up jena-top:
> 
> e.g. jena-iri
> (currently, I've remove the "relative POM" link)
> 
> This may be clock drift but I've tried dropping the obvious wrong slave
> (windows1)
> 
> == Warning in Jenkins configuration of nightly builds.
> 
> If I make any change to the configuration of a nightly build, a warning
> is given:
> 
> 
> """
> Do you really mean "every minute" when you say "* */12 * * *"? Perhaps
> you meant "0 */12 * * *"
> """
> 
> under the "Schedule" box.
> 
> Does this need fixing?

Yes, my mistake. Easy to fix.

> == Upstream projects
> 
> The "upstream projects" seems inconsistent - I don't always see the
> right dependencies as upstream projects.
> 
> This may be a change over problem but it may be deeper.

Having two pom.xml files per projects is unusual and Jenkins or some of
the plugins Jenkins use might be confused.

Paolo

> 
>     Andy