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 12:04:43 GMT
Hi Bengt,

I don't think that the behaviour changed in any Karaf version. I don't 
think any bug has been fixed around.
It should work with any Karaf >= 2.2.0 version.

Regards
JB

On 02/03/2012 12:59 PM, Bengt Rodehav wrote:
> Just to clarify,
>
> Did this behaviour change in some version of Karaf (2.2.0?)? I mean is this
> a known bug that has been corrected?
>
> /Bengt
>
> 2012/2/3 Jean-Baptiste Onofré<jb@nanthrax.net>
>
>> Hi Bengt,
>>
>> no I mean in any version since 2.2.0: if you remove all repositories in
>> etc/org.ops4j.pax.url.mvn.cfg, you will be in offline mode (it means that
>> Karaf will use only artifacts present in the system repo).
>>
>> Regards
>> JB
>>
>>
>> On 02/03/2012 09:44 AM, Bengt Rodehav wrote:
>>
>>> Thanks I appreciate it.
>>>
>>> When you say it's already available I guess you mean on trunk - right? I
>>> think the problems I've had was on version 2.2.0 (I haven't tested since).
>>> At that time I don't think removing all repositories helped. There were
>>> still some default search that was not disabled (possibly to Central). Has
>>> this behaviour changed on trunk?
>>>
>>> /Bengt
>>>
>>> 2012/2/3 Jean-Baptiste Onofré<jb@nanthrax.net>
>>>
>>>   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.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> 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é
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message