The maven url handler has been deprecated because there was no foreseen problems with it and aether seemed a good replacement for it. We could easily say we want to maintain it and I think that would un-deprecate it ;-)
On Wednesday, March 7, 2012, Andreas Pieber <[email protected]> wrote: > 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 syst -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
