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 <[email protected]> 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 http://fusesource.com
