Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAHXGaZ6qwuvM=psW-2tm=GE5pYgxo899M2oajKXV=GPfo=CVQQ@mail.gmail.com>
References: <4F2A51A6.1010401@nanthrax.net>
	<CAHXGaZ6qwuvM=psW-2tm=GE5pYgxo899M2oajKXV=GPfo=CVQQ@mail.gmail.com>
Date: Thu, 2 Feb 2012 18:36:43 +0100
Message-ID: 
 <CAHXGaZ78BN1QR1B+TAxBzwcy2SDRA1dT7oToPPTGsEVvG4oqMg@mail.gmail.com>
Subject: Re: [INFO] System repo, artifacts resolution and aether
From: Toni Menzel <toni@okidokiteam.com>
To: dev@karaf.apache.org
Content-Type: multipart/alternative; boundary=bcaec5299589bc212704b7fea3eb

--bcaec5299589bc212704b7fea3eb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

FYI, with "making the link URL handler more clever" i mean probably
encoding the Maven coordinates (GAV) into the link url somehow (by
convention), so that it allows to fallback to some other handler (aether
e.g.) when the link cannot be resolved. Not sure yet. Maybe you guys have
an idea?

On Thu, Feb 2, 2012 at 6:33 PM, Toni Menzel <toni@okidokiteam.com> wrote:

> One thing you can do is using "link" URLs.
> This is implemented in the pax-url-link project and resolves URLs like:
> link:classpath:META-INF/links/junit.link to an InputStream that contains
> text with first line treated as the real URL.
> So, for example, if you include a file with content:
> mvn:org.junit/junit/4.8.2
> in Classpath at location /META-INF/links/junit.link, you will get the
> maven resolution.
> But you also could have another runtime dependency resolving the
> aforementioned link in class path like:
> classpath:junit.jar
> which then would use an embedded jar.
> You see this brings in some indirection into the resolving process.
> In Karaf i could think of shipping a "batteries-included" artifact that
> includes many frequently used components, another (maybe an enterprise.ja=
r)
> that contains another set of embedded batteries.
> Good thing is, you never lose the ability to possibly fall back to mvn
> resolvers taking down the artifact from outer space (online maven).
>
> Did you consider this, yet?
> Toni
>
> On Thu, Feb 2, 2012 at 10:04 AM, Jean-Baptiste Onofr=E9 <jb@nanthrax.net>=
wrote:
>
>> Hi all,
>>
>> On Karaf trunk (3.0), we currently from an issue around artifact
>> resolution (due to pax-url/aether).
>>
>> It's something that David, Achim and I are aware, but I would like to
>> warn and inform everyone (to avoid unpredictable behaviors ;)).
>>
>> 1/ SNAPSHOT resolution
>> Currently, the system repo doesn't contain Maven metadata, sha1, Maven
>> properties files. So, Aether always downloads the SNAPSHOT from Central =
and
>> overrides the file locally in system repo.
>> For instance, if you change the Karaf features file locally in the build=
,
>> the generated distribution will embed the updated file, but this file wi=
ll
>> be overrided (when you perform feature:list or feature:list-url) by the =
one
>> on snapshot remote repo.
>> A "simple" workaround is to deploy the feature file (mvn deploy), but
>> it's really ugly.
>>
>> 2/ Karaf bootstrap time
>> A side effect is that Karaf 3.0 is really long to start and bootstrap,
>> because Karaf checkes for update for each bundles/artifacts in system re=
po.
>> I evaluated that Karaf 3 takes 10 more times than Karaf 2 to start
>> (depending of the network connection).
>>
>> I consider it as a major issue, and I'm focusing on it (on both Karaf an=
d
>> Pax URL).
>>
>> Regards
>> JB
>> --
>> Jean-Baptiste Onofr=E9
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> Toni Menzel Source <http://tonimenzel.com>
>
>


--=20
Toni Menzel Source <http://tonimenzel.com>

--bcaec5299589bc212704b7fea3eb--