karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <t...@okidokiteam.com>
Subject Re: [INFO] System repo, artifacts resolution and aether
Date Thu, 02 Feb 2012 20:05:17 GMT
On Thu, Feb 2, 2012 at 8:28 PM, Christian Schneider <chris@die-schneider.net
> wrote:

> I also think the offline feature is really important. At talend for
> example we want
> to make sure our distribution works when offline so this setting could
> also be useful for tests.
> On the other hand I would not really say that downloading artifacts on
> demand would never happen in production.
> I can very well imagine deploying a very small container and then
> downloading libs and custom applications from
> a company maven repo. Of course this is different from downloading from
> the internet but from the karaf point of view it
> is not an offline mode.

And when you think about cloud deployment, or at least a clustered setup,
you'd be thankful for one central source.  All karaf instances (technically
"naked" would take their artifacts from there.
If you want it more sophisticated (e.g. a push approach), you'd use Apache
ACE perhaps (inside Karaf). In the long run i could see some kind of deeper
integration of the two projects for initial provisioning (say, Karaf has
just the bare bone container and bootstrapping stuff, everything else comes
from an ACE Repository.
Just an idea so far..

> Christian
> Am 02.02.2012 19:24, schrieb Bengt Rodehav:
>  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>
> --
> Christian Schneider
> http://www.liquid-reality.de
> Open Source Architect
> Talend Application Integration Division http://www.talend.com

Toni Menzel Source <http://tonimenzel.com>

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