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é <j...@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<t...@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<t...@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é<j...@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é
>>>>> jbono...@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é
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
