karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [INFO] System repo, artifacts resolution and aether
Date Fri, 03 Feb 2012 05:54:50 GMT
Hi Bengt,

basically, the "offline" mode is already possible, you just have to 
remove all repositories in the etc/org.ops4j.pax.url.mvn.cfg.

However, I will add a special option in pax-url for that.


On 02/02/2012 07:24 PM, Bengt Rodehav wrote:
> Link URL looks interesting although I would regard them as a complement to
> direct maven resolving.
> I'v always considered the maven support in Karaf as a very useful feature.
> Especially during development since Karaf will pick up my newly built
> artifacts directly from my local maven repository. I'm sure it is also
> useful for populating the bundle cache directly from the Internet although
> I would never use that feature in production (I create a custom
> distribution containing everything I need instead).
> What I'm trying to say is that I don't want to take away the maven support
> since it's really useful (in development) but I would like to be able to
> control it (in production) so that:
> *Priority 1*: I can stop maven from downloading anything from the Internet
> ("offline" mode). This I think must be mandatory for any production system
> - how else do you know what code you are running?
> *Priority 2*: I can restrict maven to only use artifacts contained in my
> custom distribution (mainly the system folder). This would stop maven from
> accessing my local maven repo. This would make it easier to verify that my
> custom distribution contains everything before moving to production.
> /Bengt
> 2012/2/2 Toni Menzel<toni@okidokiteam.com>
>> 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.jar)
>>> 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é<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
>> will
>>>> 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
>> repo.
>>>> 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
>> and
>>>> Pax URL).
>>>> Regards
>>>> JB
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>> --
>>> Toni Menzel Source<http://tonimenzel.com>
>> --
>> Toni Menzel Source<http://tonimenzel.com>

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message