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 12:07:58 GMT
OK - I'll verify that,

/Bengt

2012/2/3 Jean-Baptiste Onofré <jb@nanthrax.net>

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message