pax mvn url configuration (trunk)

[David Jencks <da...@yahoo.com>]

(see also KARAF-910, PAXURL-147, PAXURL-149, PAXURL-150)

I also sent a related note about the paxurl changes I'm proposing.  This note is based on the idea that the pax url changes are OK and we make the feature service wait for the mvn url handler.  My experiments make me think this completely solves KARAF-910.

I think there are some problems with our pax mvn url configuration.

1.  What is the correct local repository?  Aether has only one local repo, and it's what it copies stuff from other repos into.  Currently we're using the maven local repo as karaf local repo, and configuring the karaf "system" repo as an additional remote repo.  That means that if there is an artifact in the system repo not in the local maven repo and you look it up using a mvn url, aether will copy it into the local maven repo.  This is, to me, an obvious and very serious bug.  I think a more correct arrangement is to set the aether local repo to be the karaf "system" repo and add the local maven repo in as an additional remote repo.  If you are using e.g. nexus you will probably need to configure the mirrorOf setting to be external:* rather than * so that the ~/.m2/repository contents aren't mirrored by nexus.  The result of this configuration is that mvn url artifacts are downloaded into the karaf system repo rather than the possible ~/.m2/repository repo, thus making karaf have much less influence on the local maven setup. (paxurl changes indicated in PAXURL-150).

2. I think there is no reason to try to turn of aether.  I'm not sure that org.ops4j.pax.url.mvn.disableAether=true actually does anything, and at best it conceals other problems with the configuration.

3. The list of remote repos looks to me obviously wrong.  Most of the repos listed are already non-snapshot and copied to central anyway.  I propose:

-org.ops4j.pax.url.mvn.repositories= \
+org.ops4j.pax.url.mvn.repositories= +\
     http://repo1.maven.org/maven2@id=central, \
-    http://repository.apache.org/content/groups/snapshots-group@id=apache@snapshots@noreleases, \
-    http://svn.apache.org/repos/asf/servicemix/m2-repo@id=servicemix, \
-    http://repository.springsource.com/maven/bundles/release@id=springsource, \
-    http://repository.springsource.com/maven/bundles/external@id=springsourceext, \
-    http://oss.sonatype.org/content/repositories/releases/@id=sonatype, \
-    http://zodiac.springsource.com/maven/bundles/release@id=zodiac-repository
+    http://repository.apache.org/content/groups/snapshots-group@id=apache@snapshots@noreleases

the servicemix m2-repo is not copied to central, but AFAICT it's not needed to run karaf (as opposed to building karaf) and we should really avoid it as much as possible.

BTW the fix for KARAF-910 involves the changes to paxurl attached to KARAF-910 and also making the feature service wait to start for the mvn url handler.

thoughts?

thanks
david jencks

Re: pax mvn url configuration (trunk)

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi David,

my comments inline:

> 1.  What is the correct local repository?  Aether has only one local repo, and it's what it copies stuff from other repos into.  Currently we're using the maven local repo as karaf local repo, and configuring the karaf "system" repo as an additional remote repo.  That means that if there is an artifact in the system repo not in the local maven repo and you look it up using a mvn url, aether will copy it into the local maven repo.  This is, to me, an obvious and very serious bug.  I think a more correct arrangement is to set the aether local repo to be the karaf "system" repo and add the local maven repo in as an additional remote repo.  If you are using e.g. nexus you will probably need to configure the mirrorOf setting to be external:* rather than * so that the ~/.m2/repository contents aren't mirrored by nexus.  The result of this configuration is that mvn url artifacts are downloaded into the karaf system repo rather than the possible ~/.m2/repository repo, thus making k
araf have much less influence on the local maven setup. (paxurl changes indicated in PAXURL-150).
+1 to fix that.

>
> 2. I think there is no reason to try to turn of aether.  I'm not sure that org.ops4j.pax.url.mvn.disableAether=true actually does anything, and at best it conceals other problems with the configuration.
AFAIR, this property comes from pax-url-mvn and pax-url-aether doesn't 
really use it. So it could be removed (on trunk) from the property file.

>
> 3. The list of remote repos looks to me obviously wrong.  Most of the repos listed are already non-snapshot and copied to central anyway.  I propose:
>
> -org.ops4j.pax.url.mvn.repositories= \
> +org.ops4j.pax.url.mvn.repositories= +\
>       http://repo1.maven.org/maven2@id=central, \
> -    http://repository.apache.org/content/groups/snapshots-group@id=apache@snapshots@noreleases, \
> -    http://svn.apache.org/repos/asf/servicemix/m2-repo@id=servicemix, \
> -    http://repository.springsource.com/maven/bundles/release@id=springsource, \
> -    http://repository.springsource.com/maven/bundles/external@id=springsourceext, \
> -    http://oss.sonatype.org/content/repositories/releases/@id=sonatype, \
> -    http://zodiac.springsource.com/maven/bundles/release@id=zodiac-repository
> +    http://repository.apache.org/content/groups/snapshots-group@id=apache@snapshots@norelease
>
> the servicemix m2-repo is not copied to central, but AFAICT it's not needed to run karaf (as opposed to building karaf) and we should really avoid it as much as possible.

I'm agree the repositories list but not for the m2-repo. Especially the 
m2-repo contains the Equinox framework artifacts (latest releases) as 
it's not on central.
If *all* artifacts for Equinox are present in the Karaf system repo, 
it's OK, but I'm not sure it's the case (I have to check).

I'm at the airport right now, and with a customer today but I will be 
able to take a look tonight.

Regards
JB

>
> BTW the fix for KARAF-910 involves the changes to paxurl attached to KARAF-910 and also making the feature service wait to start for the mvn url handler.
>
> thoughts?
>
> thanks
> david jencks
>
>
>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com