karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Proposal for pax url aether config
Date Tue, 06 Mar 2012 23:41:50 GMT
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
> >

Guillaume Nodet
Blog: http://gnodet.blogspot.com/
FuseSource, Integration everywhere

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