karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: [INFO] System repo, artifacts resolution and aether
Date Fri, 03 Feb 2012 11:59:47 GMT
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
>

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