Using pax-url offline

[Antoni Myłka]

Hi,

We're using Karaf. In our distribution we'd like the Karaf features and plugins to be installed ONLY from the ${karaf.home}/system. 

With default pax-url configuration we've had issues like (best guess, didn't investigate too much, that's how it appeared)

 - deploy a new version of the distribution with a bugfix, but karaf picks older version of a bundle from the local maven repository and the bugfix isn't visible

 - deploy a distribution on a new machine which doesn't work because we forgot to include some bundles in the distro, but everything worked because they were present in the local maven repo on the previous machine we used)

Right now we use this:

org.ops4j.pax.url.mvn.useFallbackRepositories=false

org.ops4j.pax.url.mvn.disableAether=true

org.ops4j.pax.url.mvn.defaultRepositories=file:${karaf.home}/${karaf.default.repository}@snapshots

org.ops4j.pax.url.mvn.localRepository=file:${karaf.home}/${karaf.default.repository}@snapshots

org.ops4j.pax.url.mvn.repositories=

This isn't perfect still, because even if ~/.m2 doesn't exist, karaf will create ~/.m2/repository and keep it empty. What happens if ~/.m2/repostory exists and contains different versions of bundles with the same maven coordinates? Which ones will get picked up? How to guarantee that pax-url doesn't touch anything outside ${karaf.home} and won't try to make ANY remote connections.

Antoni

[Andreas Pieber]

Hey,

On Tue, Feb 26, 2013 at 12:28 PM, Antoni Myłka <antoni...@gmail.com> wrote:

org.ops4j.pax.url.mvn.useFallbackRepositories=false

org.ops4j.pax.url.mvn.disableAether=true

org.ops4j.pax.url.mvn.defaultRepositories=file:${karaf.home}/${karaf.default.repository}@snapshots

org.ops4j.pax.url.mvn.localRepository=file:${karaf.home}/${karaf.default.repository}@snapshots

org.ops4j.pax.url.mvn.repositories=

This looks fine to me for your specific requirement.

 

This isn't perfect still, because even if ~/.m2 doesn't exist, karaf will create ~/.m2/repository and keep it empty.

I think this is a "bug" of pax-url, but I'm not sure if we can really do something about it. IIRC this is a pre caution to avoid that any future operations pick into the void...

 

What happens if ~/.m2/repostory exists and contains different versions of bundles with the same maven coordinates? Which ones will get picked up?

In your current configuration the one from ${karaf.home}/system/... The .m2 is only a fallback if your artifact isn't there (see http://team.ops4j.org/wiki/display/paxurl/Mvn+Protocol#MvnProtocol-local)

 

How to guarantee that pax-url doesn't touch anything outside ${karaf.home} and won't try to make ANY remote connections.

You've done so already...

Kind regards,

Andreas

 

Antoni

--
--
------------------
OPS4J - http://www.ops4j.org - op...@googlegroups.com
 
---
You received this message because you are subscribed to the Google Groups "OPS4J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Antoni Myłka]

Hi Andreas,

So the config is ok, and the fact the ~/.m2/repository appears is a
harmless feature.

I only hope it won't become a problem if the user that started Karaf
doesn't have rights to write in his own home folder, for security
reasons.

Thanks for the quick answer,

Antoni

2013/2/27 Andreas Pieber <anpi...@gmail.com>:

[Antoni Myłka]

Hi all,

A little remark, in case someone tries the offline pax-url config and
stumbles upon the same problem:

I just found out that the pax-url-mvn configuration from my earlier
mail breaks pax-exam. We're using this distribution as a foundation
for our integration tests in pax-exam.

karafDistributionConfiguration()
.frameworkUrl(maven().groupId("group").artifactId("artifact").type("tar.gz").version("version"))
.karafVersion("2.2.9")
.name("name")
.unpackDirectory(new File("target/junit/paxexam")),

With the "pure offline" pax-url configuration the tests started
failing with a rather cryptic error:

testMethod:TestClass.testMethod:KarafTestContainer{mvn:group/artifact/version/tar.gz}(package.TestClass)
Time elapsed: 216.109 sec <<< ERROR!
java.rmi.NotBoundException: d231a4cf-c5b3-4486-b2b4-4fa556c659cd
at sun.rmi.registry.RegistryImpl.lookup(RegistryImpl.java:106)
at sun.rmi.registry.RegistryImpl_Skel.dispatch(Unknown Source)
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:386)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:250)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:255)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:233)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:359)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.getRemoteBundleContext(RemoteBundleContextClientImpl.java:263)
at org.ops4j.pax.exam.rbc.client.intern.RemoteBundleContextClientImpl.waitForState(RemoteBundleContextClientImpl.java:234)
at org.apache.karaf.tooling.exam.container.internal.KarafTestContainer.waitForState(KarafTestContainer.java:599)
at org.apache.karaf.tooling.exam.container.internal.KarafTestContainer.start(KarafTestContainer.java:183)
at org.ops4j.pax.exam.spi.reactors.AllConfinedStagedReactor.invoke(AllConfinedStagedReactor.java:67)
at org.ops4j.pax.exam.junit.JUnit4TestRunner$2.evaluate(JUnit4TestRunner.java:285)

I started investigating and it turned out that pax exam installs its
own feature in the Karaf distribution. That feature is required for
proper functioning of tests. The bundles that comprise that feature
(listed in the examfeatures.xml file) are obviously not part of our
distribution, but they are also NOT downloaded by the normal build.
Hence we can't assume that they are present in the local repository
when the test starts. This means that in order to work, pax exam MUST
have the ability to make remote connections and download maven
artifacts. What's more, we'd like to download those bundles only once
and not separately for each test method. Our build is long enough as
it is, that's why we have to use a "normal" local repository.

That's why I created a new .cfg file for pax-exam, that looks like this:

org.ops4j.pax.url.mvn.repositories=http://repo1.maven.org/maven2
org.ops4j.pax.url.mvn.localRepository=${user.home}/.m2/repository

Then I use a config option to add those settings to the distribution
before the tests. (Default Repository is still ${karaf.home}/system).

KarafDistributionOption.editConfigurationFilePut("etc/org.ops4j.pax.url.mvn.cfg",
file)

Where 'file' is a java.io.File instance with my settings.

This gives me a fully offline distribution and the ability to use it
in pax-exam integration tests.

Antoni

2013/2/27 Antoni Myłka <antoni...@gmail.com>: