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 Wed, 07 Mar 2012 06:48:43 GMT
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 <anpieber@gmail.com> 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é <jb@nanthrax.net>
>> 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
>> 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,
>> 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
>>> 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>
>>>> I introduced the org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote flag
>>>> set it to true so that the system repo could work at all.  My thinking
>>>> 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"
>>>> 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
>>>>  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.
>>>> me this makes it unacceptable and is the biggest reason I introduced
>>>> org.ops4j.pax.url.mvn.defaultLocalRepoAsRemote flag.
>>>> - There's no actual need for the system repo.  (this might be seen as
>>>> 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

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