You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@any23.apache.org by Lewis John Mcgibbney <le...@gmail.com> on 2012/03/07 12:49:06 UTC
Nightly builds taken a turn for the worse!
Hi Guys,
As the title suggests, the nightly CI's appear to have been stricken by a
phantom illness as of late.
Having taken a bit of time this morning to look into this, I see the
following
- From ages ago, build output somehow indicates that after building every
module, Jenkins tries to build at least every module again and again! The
only log output to support this is "(didn't run)", which is not correct as
build output specifies that modules did run and that they built
successfully.
- #119, 120 & 122; the first and third failed due to the dratted
"hudson.util.IOException2" we witness occur periodically on the the
Solaris/Ubuntu slaves. Although these are not welcomed, they cannot be
attributed to Any23 as a project and it looks like we just need to live
with them. The middle was a timeout as the build exceeded 45 mins, we
terminate the builds after this period as they may be in a hung state.
- #123 & 124; these are really quite a strange ones! There were many
unresolved dependencies (namely aduna and openrdf dependencies), so I can
only assume that the remote repository hosting these dependencies was not
available or off-line for this particular build?
- #125 & 126; we now witness Simo's commit @#125 & Michele's @#126 to
address adding of custom settings file to include Aduna Software external
repo and Improved integration test: renamed test to verify Extractor
plugins detection. Added test to verify CLI plugins detection. Added
minimal Javadoc. This commit is related to issue
#ANY23-54<https://issues.apache.org/jira/browse/ANY23-54>respectively.
As of #125 this changes the nature of the failed build to
comment that
message : Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy
(default-deploy) on project any23-parent: Failed to deploy artifacts:
Could not transfer
artifact org.apache.any23:any23-parent:pom:0.7.0-incubating-20120306.133324-28
from/to apache.snapshots.https
(https://repository.apache.org/content/repositories/snapshots):
Failed to transfer file:
https://repository.apache.org/content/repositories/snapshots/org/apache/any23/any23-parent/0.7.0-incubating-SNAPSHOT/any23-parent-0.7.0-incubating-20120306.133324-28.pom.
Return code is: 401
cause : Failed to deploy artifacts: Could not transfer artifact
org.apache.any23:any23-parent:pom:0.7.0-incubating-20120306.133324-28
from/to apache.snapshots.https
(https://repository.apache.org/content/repositories/snapshots): Failed
to transfer file:
https://repository.apache.org/content/repositories/snapshots/org/apache/any23/any23-parent/0.7.0-incubating-SNAPSHOT/any23-parent-0.7.0-incubating-20120306.133324-28.pom.
Return code is: 401
So basically the latest bad output we get begins as of #125 with return
codes of 401. I've taken a look at the build configuration for Any23-trunk
builds and apart from the additional settings for Build | Goals and options
| --settings settings.xml clean deploy, there is nothing out of the
ordinary.
What is certain though is that we need to have a stable build before we can
get an RC done for the 0.7.0-incubating release!
I'm tempted to open a Jira as a blocker, then get involved with either some
Jenkins admin's, builds@ or something similar?
Lewis
--
*Lewis*
Re: Nightly builds taken a turn for the worse!
Posted by Andy Seaborne <an...@apache.org>.
On 08/03/12 20:35, Lewis John Mcgibbney wrote:
> Hi Simo,
>
> On Thu, Mar 8, 2012 at 2:19 PM, Simone Tripodi<si...@apache.org>wrote:
>
>>
>> Which mvn command you execute?
>>
>
>
>>
>> As a side note: can you run please `mvn --version`?
>>
> lewismc@lewismc-HP-Mini-110-3100:~$ mvn -version
> Apache Maven 2.2.1 (rdebian-6)
> Java version: 1.6.0_25
> Java home: /home/lewismc/Downloads/jdk1.6.0_25/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "3.0.0-16-generic" arch: "i386" Family: "unix"
>
> Should I update here?
I have found that mvn2 will sometimes not create the "source-release"
artifact when using -Papache-release. There's no warning, no indication
except the absence of the zip file.
This has not happened with mvn3.
Andy
Re: Nightly builds taken a turn for the worse!
Posted by Lewis John Mcgibbney <le...@gmail.com>.
Hi Simo,
On Thu, Mar 8, 2012 at 2:19 PM, Simone Tripodi <si...@apache.org>wrote:
>
> Which mvn command you execute?
>
>
> As a side note: can you run please `mvn --version`?
>
lewismc@lewismc-HP-Mini-110-3100:~$ mvn -version
Apache Maven 2.2.1 (rdebian-6)
Java version: 1.6.0_25
Java home: /home/lewismc/Downloads/jdk1.6.0_25/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "3.0.0-16-generic" arch: "i386" Family: "unix"
Should I update here?
Re: Nightly builds taken a turn for the worse!
Posted by Simone Tripodi <si...@apache.org>.
very well done, I didn't even think to use that one that was mirrored
to our svn repo! kudos!
Apologize but I cannot reproduce the issue, I didn't notice it neither
on Jenkins (I forced a new deploy and went well)
Which mvn command you execute?
As a side note: can you run please `mvn --version`?
This is mine:
$ mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /Applications/apache-maven-3.0.4
Java version: 1.6.0_29, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.7.3", arch: "x86_64", family: "mac"
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Mar 8, 2012 at 2:57 PM, Lewis John Mcgibbney
<le...@gmail.com> wrote:
> Changed the repo-ext in parent pom.xml to
>
> <repositories>
> <repository>
> <id>any23-repository-external</id>
> - <url>http://any23.googlecode.com/svn/repo-ext</url>
> + <url>http://svn.apache.org/repos/asf/incubator/any23/repo-ext/</url>
> </repository>
> <!-- Specific repository for Aduna / Sesame related dependencies. -->
> <repository>
>
> And this seems to be working OK.
>
> I'm getting a problem with the basic crawler test suite here though, this
> is also still reflected within the Jenkins builds
>
> My local surefire output
>
> -------------------------------------------------------------------------------
> Test set: org.apache.any23.cli.CrawlerTest
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.788 sec
> <<< FAILURE!
> testCLI(org.apache.any23.cli.CrawlerTest) Time elapsed: 10.265 sec <<<
> FAILURE!
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:92)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertTrue(Assert.java:54)
> at org.apache.any23.cli.CrawlerTest.testCLI(CrawlerTest.java:87)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
> at
> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172)
> at
> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:78)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70)
>
> On Thu, Mar 8, 2012 at 10:42 AM, Lewis John Mcgibbney <
> lewis.mcgibbney@gmail.com> wrote:
>
>> Hi Again,
>>
>> After sending I thought I would read through my comments again... I think
>> I need to clarify here.
>>
>>
>> On Thu, Mar 8, 2012 at 10:29 AM, Lewis John Mcgibbney <
>> lewis.mcgibbney@gmail.com> wrote:
>>
>>> I simply don't know enough about it. There was (and is) a rather
>>> interesting thread going on elsewhere just now regarding namespaces...
>>> maybe we could rename packages to our own namespace and ship with them
>>> until we can refactor these libraries out for the next incubating release,
>>> or alternatively wait until they are available elsewhere e.g.
>>> respotitory.apache.org or maven central repos?
>>>
>>>>
>>>> By 'renaming the packages' I refer solely to ASLv2.0 licensed e.g.
>>
>> From Any23googlecode repos
>> - org.apache.commons.commons-csv rename to
>> org.apache.any23.commons.commons-csv
>>
>> -net.xeoh.jspf appears to be BSD licensed so we obviously can't muck
>> around with namespaces and pacxkages here. Apache James seems to have some
>> kind of jspf implementation though. [1]
>>
>> I've just noticed halfway though writing this email that we actually
>> maintain our own svn repo-ext with both of the above libraries included.
>> Can we not simply change the dependency resolution to point to this repos?
>>
>> [1] http://search.maven.org/#search|ga|1|jspf
>>
>
>
>
> --
> *Lewis*
Re: Nightly builds taken a turn for the worse!
Posted by Andy Seaborne <an...@apache.org>.
On 08/03/12 13:57, Lewis John Mcgibbney wrote:
> Changed the repo-ext in parent pom.xml to
>
> <repositories>
> <repository>
> <id>any23-repository-external</id>
> -<url>http://any23.googlecode.com/svn/repo-ext</url>
> +<url>http://svn.apache.org/repos/asf/incubator/any23/repo-ext/</url>
> </repository>
> <!-- Specific repository for Aduna / Sesame related dependencies. -->
> <repository>
>
> And this seems to be working OK.
Nice!
Andy
Re: Nightly builds taken a turn for the worse!
Posted by Lewis John Mcgibbney <le...@gmail.com>.
Changed the repo-ext in parent pom.xml to
<repositories>
<repository>
<id>any23-repository-external</id>
- <url>http://any23.googlecode.com/svn/repo-ext</url>
+ <url>http://svn.apache.org/repos/asf/incubator/any23/repo-ext/</url>
</repository>
<!-- Specific repository for Aduna / Sesame related dependencies. -->
<repository>
And this seems to be working OK.
I'm getting a problem with the basic crawler test suite here though, this
is also still reflected within the Jenkins builds
My local surefire output
-------------------------------------------------------------------------------
Test set: org.apache.any23.cli.CrawlerTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.788 sec
<<< FAILURE!
testCLI(org.apache.any23.cli.CrawlerTest) Time elapsed: 10.265 sec <<<
FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at org.apache.any23.cli.CrawlerTest.testCLI(CrawlerTest.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
at
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172)
at
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:78)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70)
On Thu, Mar 8, 2012 at 10:42 AM, Lewis John Mcgibbney <
lewis.mcgibbney@gmail.com> wrote:
> Hi Again,
>
> After sending I thought I would read through my comments again... I think
> I need to clarify here.
>
>
> On Thu, Mar 8, 2012 at 10:29 AM, Lewis John Mcgibbney <
> lewis.mcgibbney@gmail.com> wrote:
>
>> I simply don't know enough about it. There was (and is) a rather
>> interesting thread going on elsewhere just now regarding namespaces...
>> maybe we could rename packages to our own namespace and ship with them
>> until we can refactor these libraries out for the next incubating release,
>> or alternatively wait until they are available elsewhere e.g.
>> respotitory.apache.org or maven central repos?
>>
>>>
>>> By 'renaming the packages' I refer solely to ASLv2.0 licensed e.g.
>
> From Any23googlecode repos
> - org.apache.commons.commons-csv rename to
> org.apache.any23.commons.commons-csv
>
> -net.xeoh.jspf appears to be BSD licensed so we obviously can't muck
> around with namespaces and pacxkages here. Apache James seems to have some
> kind of jspf implementation though. [1]
>
> I've just noticed halfway though writing this email that we actually
> maintain our own svn repo-ext with both of the above libraries included.
> Can we not simply change the dependency resolution to point to this repos?
>
> [1] http://search.maven.org/#search|ga|1|jspf
>
--
*Lewis*
Re: Nightly builds taken a turn for the worse!
Posted by Lewis John Mcgibbney <le...@gmail.com>.
Hi Again,
After sending I thought I would read through my comments again... I think I
need to clarify here.
On Thu, Mar 8, 2012 at 10:29 AM, Lewis John Mcgibbney <
lewis.mcgibbney@gmail.com> wrote:
> I simply don't know enough about it. There was (and is) a rather
> interesting thread going on elsewhere just now regarding namespaces...
> maybe we could rename packages to our own namespace and ship with them
> until we can refactor these libraries out for the next incubating release,
> or alternatively wait until they are available elsewhere e.g.
> respotitory.apache.org or maven central repos?
>
>>
>> By 'renaming the packages' I refer solely to ASLv2.0 licensed e.g.
>From Any23googlecode repos
- org.apache.commons.commons-csv rename to
org.apache.any23.commons.commons-csv
-net.xeoh.jspf appears to be BSD licensed so we obviously can't muck around
with namespaces and pacxkages here. Apache James seems to have some kind of
jspf implementation though. [1]
I've just noticed halfway though writing this email that we actually
maintain our own svn repo-ext with both of the above libraries included.
Can we not simply change the dependency resolution to point to this repos?
[1] http://search.maven.org/#search|ga|1|jspf
Re: Nightly builds taken a turn for the worse!
Posted by Lewis John Mcgibbney <le...@gmail.com>.
Hi,
On Thu, Mar 8, 2012 at 9:16 AM, Simone Tripodi <si...@apache.org>wrote:
> Build restored, and apologize once again :(
>
Simo no hassle at all.
>
> I still have to verify if external repositories would block the
> release, yesterday I talked with an good Infra friend, he said he
> doesn't suppose that should be blocking - I need anyway a
> confirmation.
>
I simply don't know enough about it. There was (and is) a rather
interesting thread going on elsewhere just now regarding namespaces...
maybe we could rename packages to our own namespace and ship with them
until we can refactor these libraries out for the next incubating release,
or alternatively wait until they are available elsewhere e.g.
respotitory.apache.org or maven central repos?
>
> All the best, have a nice day!
>
None-the-less thanks for having a crack at this Simo.Same to you.
Re: Nightly builds taken a turn for the worse!
Posted by Simone Tripodi <si...@apache.org>.
Build restored, and apologize once again :(
I still have to verify if external repositories would block the
release, yesterday I talked with an good Infra friend, he said he
doesn't suppose that should be blocking - I need anyway a
confirmation.
All the best, have a nice day!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Mar 7, 2012 at 1:11 PM, Simone Tripodi <si...@apache.org> wrote:
> Hi Lewis,
>
> for the Jenkis part it's my fault *blush* just let me find a cycle of
> 15 minutes (unfortunately I cannot work fulltime on OSS activities)
> and I'll adjust the build!
>
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Wed, Mar 7, 2012 at 12:49 PM, Lewis John Mcgibbney
> <le...@gmail.com> wrote:
>> Hi Guys,
>>
>> As the title suggests, the nightly CI's appear to have been stricken by a
>> phantom illness as of late.
>>
>> Having taken a bit of time this morning to look into this, I see the
>> following
>>
>> - From ages ago, build output somehow indicates that after building every
>> module, Jenkins tries to build at least every module again and again! The
>> only log output to support this is "(didn't run)", which is not correct as
>> build output specifies that modules did run and that they built
>> successfully.
>> - #119, 120 & 122; the first and third failed due to the dratted
>> "hudson.util.IOException2" we witness occur periodically on the the
>> Solaris/Ubuntu slaves. Although these are not welcomed, they cannot be
>> attributed to Any23 as a project and it looks like we just need to live
>> with them. The middle was a timeout as the build exceeded 45 mins, we
>> terminate the builds after this period as they may be in a hung state.
>> - #123 & 124; these are really quite a strange ones! There were many
>> unresolved dependencies (namely aduna and openrdf dependencies), so I can
>> only assume that the remote repository hosting these dependencies was not
>> available or off-line for this particular build?
>> - #125 & 126; we now witness Simo's commit @#125 & Michele's @#126 to
>> address adding of custom settings file to include Aduna Software external
>> repo and Improved integration test: renamed test to verify Extractor
>> plugins detection. Added test to verify CLI plugins detection. Added
>> minimal Javadoc. This commit is related to issue
>> #ANY23-54<https://issues.apache.org/jira/browse/ANY23-54>respectively.
>> As of #125 this changes the nature of the failed build to
>> comment that
>>
>> message : Failed to execute goal
>> org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy
>> (default-deploy) on project any23-parent: Failed to deploy artifacts:
>> Could not transfer
>> artifact org.apache.any23:any23-parent:pom:0.7.0-incubating-20120306.133324-28
>> from/to apache.snapshots.https
>> (https://repository.apache.org/content/repositories/snapshots):
>>
>> Failed to transfer file:
>> https://repository.apache.org/content/repositories/snapshots/org/apache/any23/any23-parent/0.7.0-incubating-SNAPSHOT/any23-parent-0.7.0-incubating-20120306.133324-28.pom.
>> Return code is: 401
>> cause : Failed to deploy artifacts: Could not transfer artifact
>> org.apache.any23:any23-parent:pom:0.7.0-incubating-20120306.133324-28
>> from/to apache.snapshots.https
>> (https://repository.apache.org/content/repositories/snapshots): Failed
>> to transfer file:
>>
>> https://repository.apache.org/content/repositories/snapshots/org/apache/any23/any23-parent/0.7.0-incubating-SNAPSHOT/any23-parent-0.7.0-incubating-20120306.133324-28.pom.
>>
>> Return code is: 401
>>
>> So basically the latest bad output we get begins as of #125 with return
>> codes of 401. I've taken a look at the build configuration for Any23-trunk
>> builds and apart from the additional settings for Build | Goals and options
>> | --settings settings.xml clean deploy, there is nothing out of the
>> ordinary.
>>
>> What is certain though is that we need to have a stable build before we can
>> get an RC done for the 0.7.0-incubating release!
>>
>> I'm tempted to open a Jira as a blocker, then get involved with either some
>> Jenkins admin's, builds@ or something similar?
>>
>> Lewis
>>
>>
>> --
>> *Lewis*
Re: Nightly builds taken a turn for the worse!
Posted by Simone Tripodi <si...@apache.org>.
Hi Lewis,
for the Jenkis part it's my fault *blush* just let me find a cycle of
15 minutes (unfortunately I cannot work fulltime on OSS activities)
and I'll adjust the build!
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Mar 7, 2012 at 12:49 PM, Lewis John Mcgibbney
<le...@gmail.com> wrote:
> Hi Guys,
>
> As the title suggests, the nightly CI's appear to have been stricken by a
> phantom illness as of late.
>
> Having taken a bit of time this morning to look into this, I see the
> following
>
> - From ages ago, build output somehow indicates that after building every
> module, Jenkins tries to build at least every module again and again! The
> only log output to support this is "(didn't run)", which is not correct as
> build output specifies that modules did run and that they built
> successfully.
> - #119, 120 & 122; the first and third failed due to the dratted
> "hudson.util.IOException2" we witness occur periodically on the the
> Solaris/Ubuntu slaves. Although these are not welcomed, they cannot be
> attributed to Any23 as a project and it looks like we just need to live
> with them. The middle was a timeout as the build exceeded 45 mins, we
> terminate the builds after this period as they may be in a hung state.
> - #123 & 124; these are really quite a strange ones! There were many
> unresolved dependencies (namely aduna and openrdf dependencies), so I can
> only assume that the remote repository hosting these dependencies was not
> available or off-line for this particular build?
> - #125 & 126; we now witness Simo's commit @#125 & Michele's @#126 to
> address adding of custom settings file to include Aduna Software external
> repo and Improved integration test: renamed test to verify Extractor
> plugins detection. Added test to verify CLI plugins detection. Added
> minimal Javadoc. This commit is related to issue
> #ANY23-54<https://issues.apache.org/jira/browse/ANY23-54>respectively.
> As of #125 this changes the nature of the failed build to
> comment that
>
> message : Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy
> (default-deploy) on project any23-parent: Failed to deploy artifacts:
> Could not transfer
> artifact org.apache.any23:any23-parent:pom:0.7.0-incubating-20120306.133324-28
> from/to apache.snapshots.https
> (https://repository.apache.org/content/repositories/snapshots):
>
> Failed to transfer file:
> https://repository.apache.org/content/repositories/snapshots/org/apache/any23/any23-parent/0.7.0-incubating-SNAPSHOT/any23-parent-0.7.0-incubating-20120306.133324-28.pom.
> Return code is: 401
> cause : Failed to deploy artifacts: Could not transfer artifact
> org.apache.any23:any23-parent:pom:0.7.0-incubating-20120306.133324-28
> from/to apache.snapshots.https
> (https://repository.apache.org/content/repositories/snapshots): Failed
> to transfer file:
>
> https://repository.apache.org/content/repositories/snapshots/org/apache/any23/any23-parent/0.7.0-incubating-SNAPSHOT/any23-parent-0.7.0-incubating-20120306.133324-28.pom.
>
> Return code is: 401
>
> So basically the latest bad output we get begins as of #125 with return
> codes of 401. I've taken a look at the build configuration for Any23-trunk
> builds and apart from the additional settings for Build | Goals and options
> | --settings settings.xml clean deploy, there is nothing out of the
> ordinary.
>
> What is certain though is that we need to have a stable build before we can
> get an RC done for the 0.7.0-incubating release!
>
> I'm tempted to open a Jira as a blocker, then get involved with either some
> Jenkins admin's, builds@ or something similar?
>
> Lewis
>
>
> --
> *Lewis*