Pax-Exam should respect the maven.repo.local system property [PAXEXAM-543]

ops4j-issues commented 11 years ago

Robert Munteanu created PAXEXAM-543

When running Maven builds, CI containers can be configured to use a different local repository, to better isolate concurrent builds and also to ensure that builds are reproducible. Jenkins does this usually via the maven.repo.local system property. Pax-Exam does not support it out of the box, so I need to work around it using code like

String localRepo = System.getProperty("maven.repo.local", "");
// other stuff...
when(localRepo.length() > 0).useOptions(
    systemProperty("org.ops4j.pax.url.mvn.localRepository").value(localRepo)
)

It would be good if Pax-Exam would do this out of the box. The error message when I fail to do this is quite confusing, and the error is hard to track down:

java.io.IOException: Error resolving artifact org.apache.sling:org.apache.sling.hc.core:jar:0.0.1-SNAPSHOT: Could not find artifact org.apache.sling:org.apache.sling.hc.core:jar:0.0.1-SNAPSHOT in central (http://repo1.maven.org/maven2/)

Affects: 3.0.3 Votes: 0, Watches: 8

ops4j-issues commented 11 years ago

Andreas Veithen commented

I encountered the same issue with Apache Axiom on our Jenkins instance (the build is configured to use a private local Maven repository). Note that the problem is not limited to the location of the local Maven repository. There are a couple of other settings that are not taken into account automatically by the mvn URL provider:

Repositories configured in the POM. Some have argued 1 that declaring repositories in POMs is discouraged. That argument is correct for repositories containing release artifacts, but not for snapshot repositories: all release dependencies should indeed be in Maven central, but dependencies on snapshot versions from upstream projects necessarily require configuration of additional repositories. The right place to configure these repositories is in the POM, not in settings.xml.
Offline mode. This mode is enabled using the -o switch on the mvn command, but Pax Exam has no way to detect this and will continue trying to access remote hosts.
There are probably other settings that will cause problems, such as non standard Wagon providers used to access certain repositories.

Personally I think that the whole concept of having Pax Exam resolve Maven dependencies on its own completely sucks (when Pax Exam is executed inside a Maven build) because there is no way to ensure that what Pax Exam does is consistent with the underlying Maven build.

To solve the problem in the Apache Axiom build, I took a different approach which is to write a small Maven plugin 2 that scans the Maven dependencies for OSGi bundles and that produce a set of link files (that contain file URLs pointing directly to the local Maven repository). In the unit tests, I can then provision these bundles using link:classpath:*.link URLs 3. That works like a charm.

1 https://groups.google.com/forum/#!msg/ops4j/kRxAXidbt7A/w0i6tM1Mn9MJ
2 https://svn.apache.org/repos/asf/webservices/axiom/trunk/buildutils/paxexam-maven-plugin/src/main/java/org/apache/axiom/buildutils/pax/exam/maven/GenerateLinkFilesMojo.java
3 https://svn.apache.org/repos/asf/webservices/axiom/trunk/systests/osgi-tests/src/test/java/org/apache/axiom/test/JAXBTest.java

ops4j-issues commented 11 years ago

Achim Nierbeck commented

Andreas Veithen - as this is a open source project, contributions are always welcome. Just give us your github ID and we'll give you access right away. This is much more productive then just complaining. If something sucks try to improve it by either a open discussion but best by contributing code. That's the way OPS4J works, just get yourself involved.

ops4j-issues commented 11 years ago

Andreas Veithen commented

The purpose of my comment was to provoke some reactions and to see what other people think about the alternative approach that I propose (I'm only an occasional user of Pax Exam, so there may be better ways). In the meantime I also wrote a blog post that expands a bit on these ideas:

http://veithen.blogspot.be/2013/09/using-pax-exam-in-maven-builds.html

Since I needed to stabilize the Apache Axiom build, I added the code there, but I'm certainly ready to improve it and contribute it to the Pax project. Let's see if there are other reactions and then we can discuss how this code should be integrated in the Pax project. Should I start a thread in the OPS4J forum?

ops4j-issues commented 11 years ago

Achim Nierbeck commented

Yes a discussion at the ops4j mailinglist is usually best to start a discussion :wink:
and while at it add your github ID and I'll add you to the dev list :grinning:

ops4j-issues commented 11 years ago

Andreas Veithen commented

Done. My github ID is "veithen".

ops4j-issues commented 11 years ago

Achim Nierbeck commented

added

ops4j-issues commented 11 years ago

Harald Wellmann commented

The comments, while containing some interesting ideas, do not really address the issue. The mailing list is a better place for general discussions.

Coming back to the original issue, Pax Exam does not directly interact with Maven at all. Maven bundle provisioning is handled by the Pax URL mvn: protocol handler, and any extensions for Maven system properties would be better located in Pax URL.