OK - I think I understand the process. The lack of package makes for an
explanation. We can easily set the Java8 job to be "mvn verify"
(probably it should be; the main test job is "verify" for the RAT errors).
Java8 job updated - seems preferable (= more stable) to changes to the
build lifecycle.
(The Jenkins configuration is not in git - a PR would be for ... err,
well, tricky.).
I don't think we have had problems with a non-private repo before. Jena
does not depend on outside SNAPSHOTs and the build is a single build.
The biggest cause of problems for Jena/Jenkins are external factors. The
Apache Jenkins build system is often under heavy load to the point where
a slave goes bad, timeouts go astray, or it can't connect to git properly.
Andy
On 09/02/15 14:07, Stian Soiland-Reyes wrote:
Apologies for not spotting this email earlier. Monday Inbox Symptom.
org.apache.jena.iri etc. class files would be directly in the JAR file
from jena-osgi, and so the <scope>provided</scope> shouldn't matter.
It does however require the jena-osgi.jar to exist, which is built by
"mvn package".
In your log, maven-bundle-plugin didn't execute in jena-osgi. I don't
see any log outputs from it - you would normally see:
[INFO] --- maven-bundle-plugin:2.5.3:bundle (default-bundle) @ jena-osgi ---
[WARNING] Bundle org.apache.jena:jena-osgi:bundle:2.13.0-SNAPSHOT : Unused
Private-Package instructions, no such package(s) on the class path: [!*]
(..)
Probably this is because the phase binds to 'package' by default -
which comes after 'test'.
http://svn.apache.org/repos/asf/felix/releases/maven-bundle-plugin-2.5.3/doc/site/bundle-mojo.html
So the solution would be either:
test
a) In Jenkins, run "mvn verify" instead of "mvn test"
.. but anyway other could be doing 'test' - -- in which case the
test-compilation of jena-osgi-test probably should be post-poned in
pre-integration-test and run on integration-test (those are covered by
verify which follows package)
b) Execute maven-bundle-plugin earlier than 'package'. This might be
odd as the other modules would not have any JARs in their target/
folders if you only do 'mvn test'
Shall I prepare a pull request for a)?
I see the Jenkins build also does:
-Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/1
This seems to indicate you are using a shared Maven repository for the
Jenkins - shared as with together with 100 other projects. I have
found that to be quite unstable.. as it can lead to dependency on
side-effects from other jobs and wrong SNAPSHOTs sneaking in. Perhaps
we should also tick the box "Private Maven repository" turned on in
Jenkins?
On 7 February 2015 at 21:07, Andy Seaborne <[email protected]> wrote:
Full details:
https://builds.apache.org/user/andy/my-views/view/Jena/job/Jena_Development_Test_Java8/168/console
Summary:
[INFO] Building Apache Jena - OSGi bundle tests 2.13.0-SNAPSHOT
[ERROR] COMPILATION ERROR :
[ERROR]
/home/jenkins/jenkins-slave/workspace/Jena_Development_Test_Java8/apache-jena-osgi/jena-osgi-test/src/main/java/org/apache/jena/osgi/test/JenaOSGITestImpl.java:[30,27]
package org.apache.jena.iri does not exist
[ERROR]
/home/jenkins/jenkins-slave/workspace/Jena_Development_Test_Java8/apache-jena-osgi/jena-osgi-test/src/main/java/org/apache/jena/osgi/test/JenaOSGITestImpl.java:[31,27]
package org.apache.jena.iri does not exist
.. and many more ..
This Jenkins runs to run "mvn test" with a Java8 setup. It does not install
artifacts in any maven repositories.
We have several test jobs:
* Jena_Development_Test
* Jena_Development_Test_Java8
* Jena_New_Tests
Would I be right in assuming this build failure occurs because the test job
can't find <scope>provided</scope> artifacts?
The version changed recently from 2.12.2 to 2.13.0. Guess: The Java8 job
happened to be one a slave (H10) where there were no artifacts yet.
I think the H* slaves are not general purpose like the ubuntu* ones, being
configured for Hadoop. They become available sometimes for general jobs as
ubuntu* become full.
Andy
