karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jb@nanthrax.net" ...@nanthrax.net>
Subject Re: aether url handler problems and proposed solutions
Date Tue, 10 Jan 2012 05:17:02 GMT
Hi David,

+1 for all (with 1b).


Jean-Baptiste Onofré
Talend - http://wwx.talend.com

----- Reply message -----
From: "David Jencks" <david_jencks@yahoo.com>
To: "General OPS4J" <general@lists.ops4j.org>, <dev@karaf.apache.org>
Subject: aether url handler problems and proposed solutions
Date: Tue, Jan 10, 2012 12:13 am

At the risk of causing total confusion, I'm going to discuss more than one issue in this email.
 Please consider looking at the whole message, not just the first problem.

1. Configuration source (PAXURL-147, KARAF-910).  Karaf uses the pax mvn (aether) url handler
during initial startup, and tries to supply a config admin based configuration for it.  Currently
this is stymied by the behavior of using framework properties initially, then replacing them
with config admin configuration when available.  Here are some requirements:

-  Karaf needs a solution whereby the url handler is not registered until the config admin
configuration is in place.
- The url handler needs to be usable with no configuration at all
- The url handler needs to be usable with framework property configuration

proposed solution:
1.a. add a flag org.ops4j.pax.url.mvn.requireConfigAdminConfig that can be configured in framework
properties.  When set in a configuration source, the configuration source will be treated
as not valid and will not result in the url handler being registered.
1.b make the config admin based configuration NOT use the framework property based configuration
as fallback.  This means that the config admin based configuration source will not see the
flag above if it's set only in the framework properties.

I think that 1.b is a good change in any case.  If you want to use config admin based configuration,
use it!

With a couple simple changes in karaf feature service to wait for the url handler, this seems
to solve the problems we've been having with karaf as far as using an unconfigured url handler.

2. Problems with repo management in the aether url handler.

2.1 (PAXURL-149) Mirrored repos are not fully mirrored: they are still consulted directly.
 This really defeats the purpose of mirroring.  In more detail, if a repo is mirrored, the
mirror is added to the beginning of the list of remote repos, but the mirrored repo is left
in the list. So for instance if you have configured your local nexus repo to block downloading
of some urls, the presence of the original repo after the mirror will mean that the urls can
be downloaded directly anyway.

Solution:  remove the mirrored repos from the list of remote repos when adding the mirror.

2.2  (PAXURL-150) Local repository handling is too inflexible.  Aether can deal with only
one local repo, as the place stuff is downloaded to.  In karaf, we have a "system" repo inside
the karaf directory structure that should be used as the download location.  This is required
because it's possible to get a bundle in the system repo that you want to install using a
mvn: url but you do NOT want to get into the ~/.m2/repository local maven repo.  If karaf
uses the ~/.m2/repository as the local repo and adds the karaf system as an additional remote
repo, aether will "download" the bundle into the ~/.m2/repository repo.  Therefore the karaf
system repo should be configured as the local repository and the ~/.m2/repository local maven
repository should be configured as an additional remote repo.  However the location of this
repo is not known in advance since it can be configured in settings.xml.

Solution: add a flag org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote that when set will find
the actual location of the maven local repo from settings.xml and add it to the list of remote
Possible alternate solution: if org.ops4j.pax.url.mvn.localRepository is set and differs from
the maven local repo, add the maven local repo as a remote repo.  This uses less configuration
but is less flexible.

Since these proposals change the behavior of the url handler I would like to discuss them
before committing.  On the other hand KARAF-910 has been a serious problem in karaf for a
long time so I would like to commit the fixes soon.

Many thanks
david jencks

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message