karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Proposal for pax url aether config
Date Wed, 07 Mar 2012 06:04:40 GMT
Hi David and Guillaume,

David, what you describe was possible with pax-url-mvn, not with 

I don't want to introduce a "system" URL handling as it's a big change 
for the user and all projects with depending features.
I'm strongly against (2) because Maven system repo is a key feature 
since the first version of Karaf. It's the way that KARs work, features 
work, etc.

So we have three solutions right now:
- keep it as it is but we know that some stuff will not work (like 
- consider the local repo and introduce "redundancy" as most of 
artifacts will be copied into the system repo
- enhance pax-url-aether to match our need
- get back to pax-url-mvn, it have some impacts as we upgraded the 
karaf-maven-plugin and some command to use aether

So, if we want the same behavior as in karaf 2.2.x, I would get back to 
pax-url-mvn on Karaf and rollback all aether usage.


On 03/07/2012 12:41 AM, Guillaume Nodet wrote:
> I agree with this analysis.
> Just to follow on, I think what you describe is mostly what we had for a
> long time in the 2.x branch (but the fact that we were needing the mvn url
> handler but not the aether one)..  Should we simply get back to that ?
> On Tue, Mar 6, 2012 at 23:29, David Jencks<david_jencks@yahoo.com>  wrote:
>> I introduced the org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote flag and
>> set it to true so that the system repo could work at all.  My thinking on
>> mvn urls has changed considerably since then.
>> I think there are two plausible choices:
>> 1. keep the system repo as the local maven repo in karaf and treat the
>> ~/.m2/repository repo as a remote repo.  IIUC this prevents "watch" from
>> working unless you push the snapshots into the system repo.
>> 2. don't pretend that the system repo is a maven repo at all, and don't
>> try to use mvn urls with it.  Use mvn urls for stuff you don't plan to put
>> in the system repo at all.  Use the normal mvn configuration unchanged.
>>   Either flatten the directory structure or introduce something like a
>> "system" url handler that just looks in system using the same url structure
>> as the mvn handler.
>> After considering the matter for a couple of months now, I'm very strongly
>> in favor of (2).
>> Problems with (1):
>> - Everything you use a mvn url for will get copied into the system repo.
>>   This is highly redundant.
>> - you need the maven metadata files cluttering up the universe
>> - There's rarely a guarantee that something you put in the system repo
>> will be what's used, whether or not you intend to use it.
>> - Scanning the universe for more recent snapshots unnecessarily slows down
>> startup
>> - karaf won't work without the giant aether url handler which pulls in
>> tons of barely related code.
>> Problems with your proposed solution:
>> - everything in the system repo, unless overridden by something remote
>> that might be more recent, will get copied into the local maven repo.  To
>> me this makes it unacceptable and is the biggest reason I introduced the
>> org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote flag.
>> - There's no actual need for the system repo.  (this might be seen as an
>> advantage)
>> - Everything (except startup bundles) is filtered through the mvn url
>> handler which may not be what you want.
>> Advantage of not using the mvn url handler for the system repo:
>> - the mvn url handler becomes optional and karaf can be self contained
>> - you can be sure if you put something in system that's what will be used.
>> - startup for anything in system  should be much faster
>> So right now I'm about
>> -10 on (1)
>> -100 on your proposal
>> +1 on (2)
>> Note also that right now startup.properties looks like it's using mvn urls
>> but in fact they are interpreted to point into specific files in the system
>> repo.
>> This may have some impact on features and kars.  Right now feature
>> repositories are just xml files typically containing more than one feature
>> and using mvn urls.  Kar files are typically zip archives containing a
>> maven repo structure with one or more feature repositories and some
>> artifacts and some resources.
>> On the other hand the subsystem spec only has things like kar archives,
>> but the feature repository is in a manifest structured file, has only one
>> top level feature (or other subsystem) and the artifacts are in a flat
>> repository, at the root.  I don't think there's any good reason to keep the
>> maven repo structure in our kars or to unpack the contents when installing;
>> a jar: url ought to work fine.
>> thanks
>> david jencks
>> On Mar 6, 2012, at 7:28 AM, Christian Schneider wrote:
>>> I just discussed with JB how a correct config for pax url could look
>> like. I think we found a very nice solution (See below).
>>> Basically it uses the default local maven repo as a local repo and uses
>> the system dir a a remote repo.
>>> - This means the system dir is now read only
>>> - The local repo is the prefered repo to look stuff up
>>> I think this is exactly what we need. JB was first a bit concerned about
>> the local repo being looked up before the system dir. I think this should
>> not be a big problem.
>>> For released artifacts it should not matter and for snapshots looking in
>> the default local repo first is exactly what I need for my own development.
>>> In fact dev:watch now works perfectly for me again. So I propose we
>> change the pax url config to these settings.
>>> Christian
>>> ------
>>> org.ops4j.pax.url.mvn.useFallbackRepositories=false
>>> org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote=false
>>> 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,
>> \
>>>     file:${karaf.home}/${karaf.default.repository}@snapshots
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com

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

View raw message