I'm strongly in favor of option (2) as proposed by JB. option (1) might be an option since dev:watch works anyhow in a dev setting and I think runtime settings have quite different requirements and for option (3) the mvn-url-handler is deprecated in favor of the aether handler; so not sure if I should like this option...
Kind regards, Andreas On Wed, Mar 7, 2012 at 07:04, Jean-Baptiste Onofré <[email protected]> wrote: > Hi David and Guillaume, > > David, what you describe was possible with pax-url-mvn, not with > pax-url-aether. > > 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 > dev:watch) > - 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. > > Regards > JB > > > 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<[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 >>>> >>> >>> >> >> > > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com
