You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2012/02/02 10:04:38 UTC
[INFO] System repo, artifacts resolution and aether
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
Re: [INFO] System repo, artifacts resolution and aether
Posted by Toni Menzel <to...@okidokiteam.com>.
+1 (non binding *g*)
On Mon, Feb 6, 2012 at 4:41 PM, Achim Nierbeck <bc...@googlemail.com>wrote:
> Hi JB,
>
> +1 from my side, I think the cons of a small overhead can be ignored
> compared to the fully functional maven-type repo we have then :)
> cause if we don't provide them those artefacts are generated anyways.
>
> regards, Achim
>
> 2012/2/6 Jean-Baptiste Onofré <jb...@nanthrax.net>
>
> > Hi guys,
> >
> > I'm back to you with a proposal.
> >
> > Currently, as the Karaf system repo doesn't contain the artifacts
> > metadata, without this metadata, aether always download the artifact from
> > the "remote" repo.
> >
> > If we have the metadata in the Karaf system repo, if the "local" metadata
> > are newer than the remote ones, aether won't download the artifact from
> the
> > remote repo. If the metadata is newer on the remote repo, aether will
> > download the metadata and the artifact from the remote.
> > It's the normal behavior, the one expected by aether.
> >
> > So basically, including metadata in the Karaf system repo fixes our
> > problem and we have a consistent behavior.
> >
> > Aether also provides an API (a kind of installArtifact() method) which
> > generate the artifact metadata.
> >
> > So, my proposal is to enhance the Karaf Maven plugin and Pax URL to use
> > Aether API. The purpose is to have the metadata in the Karaf system repo.
> >
> > Pros:
> > - Karaf system repo is real Maven3 compliant repository
> > - We respect a Maven3 style artifact lifecycle
> >
> > Cons:
> > - We have a small overhead (in terms of space usage) in the system repo
> > (metadata properties, pom xml, etc)
> >
> > WDYT ?
> >
> > Regards
> > JB
> >
> >
> > On 02/02/2012 10:04 AM, Jean-Baptiste Onofré 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
> >
>
>
>
> --
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
>
--
Toni Menzel Source <http://tonimenzel.com>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi JB,
+1 from my side, I think the cons of a small overhead can be ignored
compared to the fully functional maven-type repo we have then :)
cause if we don't provide them those artefacts are generated anyways.
regards, Achim
2012/2/6 Jean-Baptiste Onofré <jb...@nanthrax.net>
> Hi guys,
>
> I'm back to you with a proposal.
>
> Currently, as the Karaf system repo doesn't contain the artifacts
> metadata, without this metadata, aether always download the artifact from
> the "remote" repo.
>
> If we have the metadata in the Karaf system repo, if the "local" metadata
> are newer than the remote ones, aether won't download the artifact from the
> remote repo. If the metadata is newer on the remote repo, aether will
> download the metadata and the artifact from the remote.
> It's the normal behavior, the one expected by aether.
>
> So basically, including metadata in the Karaf system repo fixes our
> problem and we have a consistent behavior.
>
> Aether also provides an API (a kind of installArtifact() method) which
> generate the artifact metadata.
>
> So, my proposal is to enhance the Karaf Maven plugin and Pax URL to use
> Aether API. The purpose is to have the metadata in the Karaf system repo.
>
> Pros:
> - Karaf system repo is real Maven3 compliant repository
> - We respect a Maven3 style artifact lifecycle
>
> Cons:
> - We have a small overhead (in terms of space usage) in the system repo
> (metadata properties, pom xml, etc)
>
> WDYT ?
>
> Regards
> JB
>
>
> On 02/02/2012 10:04 AM, Jean-Baptiste Onofré 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
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Ioannis Canellos <io...@gmail.com>.
It makes sense to me!
+1
On 7 Φεβ 2012, at 7:13 π.μ., Andreas Pieber wrote:
> I'm also +1 on this; the overhead should be marginal compared to the advantages.
>
> Kind regards,
> Andreas
>
> On Mon 06 Feb 2012 06:30:55 PM CET, Jamie G. wrote:
>> +1 sounds good to me.
>>
>> Cheers,
>> Jamie
>>
>> On Mon, Feb 6, 2012 at 12:58 PM, Christian Schneider
>> <ch...@die-schneider.net> wrote:
>>> +1
>>>
>>> Makes sense to me to make the system repo look like a real maven repo.
>>>
>>> Christian
>>>
>>>
>>> Am 06.02.2012 16:33, schrieb Jean-Baptiste Onofré:
>>>
>>>> Hi guys,
>>>>
>>>> I'm back to you with a proposal.
>>>>
>>>> Currently, as the Karaf system repo doesn't contain the artifacts
>>>> metadata, without this metadata, aether always download the artifact from
>>>> the "remote" repo.
>>>>
>>>> If we have the metadata in the Karaf system repo, if the "local" metadata
>>>> are newer than the remote ones, aether won't download the artifact from the
>>>> remote repo. If the metadata is newer on the remote repo, aether will
>>>> download the metadata and the artifact from the remote.
>>>> It's the normal behavior, the one expected by aether.
>>>>
>>>> So basically, including metadata in the Karaf system repo fixes our
>>>> problem and we have a consistent behavior.
>>>>
>>>> Aether also provides an API (a kind of installArtifact() method) which
>>>> generate the artifact metadata.
>>>>
>>>> So, my proposal is to enhance the Karaf Maven plugin and Pax URL to use
>>>> Aether API. The purpose is to have the metadata in the Karaf system repo.
>>>>
>>>> Pros:
>>>> - Karaf system repo is real Maven3 compliant repository
>>>> - We respect a Maven3 style artifact lifecycle
>>>>
>>>> Cons:
>>>> - We have a small overhead (in terms of space usage) in the system repo
>>>> (metadata properties, pom xml, etc)
>>>>
>>>> WDYT ?
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 02/02/2012 10:04 AM, Jean-Baptiste Onofré 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
>>>>
>>>>
>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
Ioannis Canellos
FuseSource
Blog: http://iocanel.blogspot.com
Apache Karaf Committer & PMC
Apache Camel Committer
Apache ServiceMix Committer
Apache Gora Committer
Apache DirectMemory Committer
Re: [INFO] System repo, artifacts resolution and aether
Posted by Andreas Pieber <an...@gmail.com>.
I'm also +1 on this; the overhead should be marginal compared to the
advantages.
Kind regards,
Andreas
On Mon 06 Feb 2012 06:30:55 PM CET, Jamie G. wrote:
> +1 sounds good to me.
>
> Cheers,
> Jamie
>
> On Mon, Feb 6, 2012 at 12:58 PM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> +1
>>
>> Makes sense to me to make the system repo look like a real maven repo.
>>
>> Christian
>>
>>
>> Am 06.02.2012 16:33, schrieb Jean-Baptiste Onofré:
>>
>>> Hi guys,
>>>
>>> I'm back to you with a proposal.
>>>
>>> Currently, as the Karaf system repo doesn't contain the artifacts
>>> metadata, without this metadata, aether always download the artifact from
>>> the "remote" repo.
>>>
>>> If we have the metadata in the Karaf system repo, if the "local" metadata
>>> are newer than the remote ones, aether won't download the artifact from the
>>> remote repo. If the metadata is newer on the remote repo, aether will
>>> download the metadata and the artifact from the remote.
>>> It's the normal behavior, the one expected by aether.
>>>
>>> So basically, including metadata in the Karaf system repo fixes our
>>> problem and we have a consistent behavior.
>>>
>>> Aether also provides an API (a kind of installArtifact() method) which
>>> generate the artifact metadata.
>>>
>>> So, my proposal is to enhance the Karaf Maven plugin and Pax URL to use
>>> Aether API. The purpose is to have the metadata in the Karaf system repo.
>>>
>>> Pros:
>>> - Karaf system repo is real Maven3 compliant repository
>>> - We respect a Maven3 style artifact lifecycle
>>>
>>> Cons:
>>> - We have a small overhead (in terms of space usage) in the system repo
>>> (metadata properties, pom xml, etc)
>>>
>>> WDYT ?
>>>
>>> Regards
>>> JB
>>>
>>> On 02/02/2012 10:04 AM, Jean-Baptiste Onofré 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
>>>
>>>
>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
Re: [INFO] System repo, artifacts resolution and aether
Posted by "Jamie G." <ja...@gmail.com>.
+1 sounds good to me.
Cheers,
Jamie
On Mon, Feb 6, 2012 at 12:58 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> +1
>
> Makes sense to me to make the system repo look like a real maven repo.
>
> Christian
>
>
> Am 06.02.2012 16:33, schrieb Jean-Baptiste Onofré:
>
>> Hi guys,
>>
>> I'm back to you with a proposal.
>>
>> Currently, as the Karaf system repo doesn't contain the artifacts
>> metadata, without this metadata, aether always download the artifact from
>> the "remote" repo.
>>
>> If we have the metadata in the Karaf system repo, if the "local" metadata
>> are newer than the remote ones, aether won't download the artifact from the
>> remote repo. If the metadata is newer on the remote repo, aether will
>> download the metadata and the artifact from the remote.
>> It's the normal behavior, the one expected by aether.
>>
>> So basically, including metadata in the Karaf system repo fixes our
>> problem and we have a consistent behavior.
>>
>> Aether also provides an API (a kind of installArtifact() method) which
>> generate the artifact metadata.
>>
>> So, my proposal is to enhance the Karaf Maven plugin and Pax URL to use
>> Aether API. The purpose is to have the metadata in the Karaf system repo.
>>
>> Pros:
>> - Karaf system repo is real Maven3 compliant repository
>> - We respect a Maven3 style artifact lifecycle
>>
>> Cons:
>> - We have a small overhead (in terms of space usage) in the system repo
>> (metadata properties, pom xml, etc)
>>
>> WDYT ?
>>
>> Regards
>> JB
>>
>> On 02/02/2012 10:04 AM, Jean-Baptiste Onofré 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
>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Christian Schneider <ch...@die-schneider.net>.
+1
Makes sense to me to make the system repo look like a real maven repo.
Christian
Am 06.02.2012 16:33, schrieb Jean-Baptiste Onofré:
> Hi guys,
>
> I'm back to you with a proposal.
>
> Currently, as the Karaf system repo doesn't contain the artifacts
> metadata, without this metadata, aether always download the artifact
> from the "remote" repo.
>
> If we have the metadata in the Karaf system repo, if the "local"
> metadata are newer than the remote ones, aether won't download the
> artifact from the remote repo. If the metadata is newer on the remote
> repo, aether will download the metadata and the artifact from the remote.
> It's the normal behavior, the one expected by aether.
>
> So basically, including metadata in the Karaf system repo fixes our
> problem and we have a consistent behavior.
>
> Aether also provides an API (a kind of installArtifact() method) which
> generate the artifact metadata.
>
> So, my proposal is to enhance the Karaf Maven plugin and Pax URL to
> use Aether API. The purpose is to have the metadata in the Karaf
> system repo.
>
> Pros:
> - Karaf system repo is real Maven3 compliant repository
> - We respect a Maven3 style artifact lifecycle
>
> Cons:
> - We have a small overhead (in terms of space usage) in the system
> repo (metadata properties, pom xml, etc)
>
> WDYT ?
>
> Regards
> JB
>
> On 02/02/2012 10:04 AM, Jean-Baptiste Onofré 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
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [INFO] System repo, artifacts resolution and aether
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi guys,
I'm back to you with a proposal.
Currently, as the Karaf system repo doesn't contain the artifacts
metadata, without this metadata, aether always download the artifact
from the "remote" repo.
If we have the metadata in the Karaf system repo, if the "local"
metadata are newer than the remote ones, aether won't download the
artifact from the remote repo. If the metadata is newer on the remote
repo, aether will download the metadata and the artifact from the remote.
It's the normal behavior, the one expected by aether.
So basically, including metadata in the Karaf system repo fixes our
problem and we have a consistent behavior.
Aether also provides an API (a kind of installArtifact() method) which
generate the artifact metadata.
So, my proposal is to enhance the Karaf Maven plugin and Pax URL to use
Aether API. The purpose is to have the metadata in the Karaf system repo.
Pros:
- Karaf system repo is real Maven3 compliant repository
- We respect a Maven3 style artifact lifecycle
Cons:
- We have a small overhead (in terms of space usage) in the system repo
(metadata properties, pom xml, etc)
WDYT ?
Regards
JB
On 02/02/2012 10:04 AM, Jean-Baptiste Onofré 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
Re: [INFO] System repo, artifacts resolution and aether
Posted by David Jencks <da...@yahoo.com>.
I've worried about this "no offline" behavior too.
For startup features I think we already analyze the mvn url and assume it applies to the system repo and directly use the file found there instead of using the mvn url handler.
I wonder if we should modify the feature service code so that it does the same: if if finds a mvn url it first checks if a corresponding artifact is in system, if so it uses it, and if not goes back to using the mvn url handler.
Or maybe we could make our own mvn url handler that does this by wrapping the pax one, or maybe a different url scheme name to do this.
I really think we're using the mvn urls in two different ways:
-- as a really convenient familiar identifier for files already in system that we want to use no matter what else might be in some other mvn repo
-- as a way to download stuff from other repos.
Or maybe we should install obr in the startup features and never use mvn urls in other features unless we want the "search the internet" behavior.
thanks
david jencks
On Feb 2, 2012, at 5:01 AM, Bengt Rodehav wrote:
> While you're looking at this problem, could you also consider making it
> possible to run Karaf in "offline" mode?
>
> I've had several issues when moving from development to production. In
> development I think that I have included all the necessary artifacts in my
> custom distribution. But then in production (where there is sometimes no
> Internet connection from the servers) it turns out that artifacts were
> missing.
>
> I have looked for a way to run Karaf in a mode similar to "mvn -o" so that
> I can verify that I have included everything. Running Karaf as a service
> (under Windows) helps since maven's local repository is not found but
> artifacts can still be downloaded from the Internet.
>
> This is not only for development though. I really do NOT want Karaf to
> download any artifacts from the Internet in production - even if it were
> possible. I only want to use the exact artifacts that have been verified in
> the testing phase.
>
> Although not exactly the problem you are looking at it seems related.
>
> /Bengt
>
> 2012/2/2 Jean-Baptiste Onofré <jb...@nanthrax.net>
>
>> Just a remark, the SNAPSHOT resolution is considered as "normal" from an
>> aether perspective as the local system repo doesn't contain metadata.
>>
>> Regards
>> JB
>>
>>
>> On 02/02/2012 10:04 AM, Jean-Baptiste Onofré 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
>>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Bengt,
thanks for reporting that, I will take a look on that too.
Regards
JB
On 02/02/2012 02:01 PM, Bengt Rodehav wrote:
> While you're looking at this problem, could you also consider making it
> possible to run Karaf in "offline" mode?
>
> I've had several issues when moving from development to production. In
> development I think that I have included all the necessary artifacts in my
> custom distribution. But then in production (where there is sometimes no
> Internet connection from the servers) it turns out that artifacts were
> missing.
>
> I have looked for a way to run Karaf in a mode similar to "mvn -o" so that
> I can verify that I have included everything. Running Karaf as a service
> (under Windows) helps since maven's local repository is not found but
> artifacts can still be downloaded from the Internet.
>
> This is not only for development though. I really do NOT want Karaf to
> download any artifacts from the Internet in production - even if it were
> possible. I only want to use the exact artifacts that have been verified in
> the testing phase.
>
> Although not exactly the problem you are looking at it seems related.
>
> /Bengt
>
> 2012/2/2 Jean-Baptiste Onofré<jb...@nanthrax.net>
>
>> Just a remark, the SNAPSHOT resolution is considered as "normal" from an
>> aether perspective as the local system repo doesn't contain metadata.
>>
>> Regards
>> JB
>>
>>
>> On 02/02/2012 10:04 AM, Jean-Baptiste Onofré 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
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [INFO] System repo, artifacts resolution and aether
Posted by Bengt Rodehav <be...@rodehav.com>.
While you're looking at this problem, could you also consider making it
possible to run Karaf in "offline" mode?
I've had several issues when moving from development to production. In
development I think that I have included all the necessary artifacts in my
custom distribution. But then in production (where there is sometimes no
Internet connection from the servers) it turns out that artifacts were
missing.
I have looked for a way to run Karaf in a mode similar to "mvn -o" so that
I can verify that I have included everything. Running Karaf as a service
(under Windows) helps since maven's local repository is not found but
artifacts can still be downloaded from the Internet.
This is not only for development though. I really do NOT want Karaf to
download any artifacts from the Internet in production - even if it were
possible. I only want to use the exact artifacts that have been verified in
the testing phase.
Although not exactly the problem you are looking at it seems related.
/Bengt
2012/2/2 Jean-Baptiste Onofré <jb...@nanthrax.net>
> Just a remark, the SNAPSHOT resolution is considered as "normal" from an
> aether perspective as the local system repo doesn't contain metadata.
>
> Regards
> JB
>
>
> On 02/02/2012 10:04 AM, Jean-Baptiste Onofré 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
>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Just a remark, the SNAPSHOT resolution is considered as "normal" from an
aether perspective as the local system repo doesn't contain metadata.
Regards
JB
On 02/02/2012 10:04 AM, Jean-Baptiste Onofré 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
Re: [INFO] System repo, artifacts resolution and aether
Posted by Bengt Rodehav <be...@rodehav.com>.
It seems like you are right JB. I did this:
On Karaf 2.2.5 I set the property "org.ops4j.pax.url.mvn.repositories" to
an empty list. I then renamed a local jar so that it could no longer be
found locally. This gave me an error when a feature needing that bundle
were to be installed.
Actually I have done this before when using Karaf 1.6.0 but for some reason
this configuration had been removed from my custom server...
I did notice that (in Karaf 2.2.5) there is also a property called
"org.ops4j.pax.url.mvn.useFallbackRepositories" which by default is set to
false. If I set it to true, then Karaf will connect to the Internet and
download artifact (from some unknown default set of repositories). I also
noticed that this option did not exist back in Karaf 1.6.0.
So...maybe (I'm guessing now), back in Karaf 1.6.0 when I had set
the "org.ops4j.pax.url.mvn.repositories" property to an empty list, perhaps
pax-url-mvn still used the fallback repositories? Back then Karaf used
version 1.1.2 of pax-url-mvn while in Karaf 2.2.5 version 1.2.8 of
pax-url-mvn is used. Just speculating...
Anyway, your suggestion works for me although I would rather have an
"offline" option if you think it's OK.
I think it's a bit tricky to configure pax-url-mvn and it would be good to
make the configuration clearer (and also document it a bit better). E g
what does the "org.ops4j.pax.url.mvn.disableAether" option actually do and
how does the resolution process work? Are we simulating maven artifact
resolution or are we actually using maven's own artifact resolution.
Thanks for your help JB,
/Bengt
2012/2/3 Bengt Rodehav <be...@rodehav.com>
> 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<to...@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<to...@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
>>
>
>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Bengt Rodehav <be...@rodehav.com>.
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<to...@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<to...@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
>
Re: [INFO] System repo, artifacts resolution and aether
Posted by 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<to...@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<to...@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
Re: [INFO] System repo, artifacts resolution and aether
Posted by Bengt Rodehav <be...@rodehav.com>.
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<to...@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<to...@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
>
Re: [INFO] System repo, artifacts resolution and aether
Posted by 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<to...@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<to...@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
Re: [INFO] System repo, artifacts resolution and aether
Posted by Bengt Rodehav <be...@rodehav.com>.
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<to...@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<to...@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
>
Re: [INFO] System repo, artifacts resolution and aether
Posted by 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<to...@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<to...@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
Re: [INFO] System repo, artifacts resolution and aether
Posted by Toni Menzel <to...@okidokiteam.com>.
On Thu, Feb 2, 2012 at 7:24 PM, Bengt Rodehav <be...@rodehav.com> 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?
>
That we can do using a switch in mvn resolver, based on.. lets say a
property setting. Must be done in Pax URL. I can add a ticket + do it.
>
> *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.
>
What you also can do is using a local, shipped with karaf maven repository
and set that as the only one (already possible)
>
>
> /Bengt
>
> 2012/2/2 Toni Menzel <to...@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 <to...@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>
> >
>
--
Toni Menzel Source <http://tonimenzel.com>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Toni Menzel <to...@okidokiteam.com>.
Please do, time to fix misbehaviors in Pax URL Aether..
On Thu, Feb 2, 2012 at 10:58 PM, Bengt Rodehav <be...@rodehav.com> wrote:
> I have been experimenting with the config.properties regarding this before
> but I remember having problems preventing the normal maven way of
> resolving. I'll take a look at this again.
>
> /Bengt
>
> 2012/2/2 Toni Menzel <to...@okidokiteam.com>
>
> > On Thu, Feb 2, 2012 at 10:03 PM, Bengt Rodehav <be...@rodehav.com>
> wrote:
> >
> > > Yes, of course there are uses for "online" mode. I hope noone believes
> > that
> > > I want to remove that possibility. It can even be the default as long
> as
> > > there are ways to "lock down" Karaf. It's both a matter of "security"
> > > (don't use unknown or untested code in production) and of "convenience"
> > > (verify in development that the installation includes everything
> needed).
> > >
> > > @Toni
> > >
> > > >What you also can do is using a local, shipped with karaf maven
> > repository
> > > >and set that as the only one (already possible)
> > >
> > > I wasn't aware of this. Can you enlighten me about how this is done?
> > >
> >
> > Well, you can always set the repositories in Pax URL via System-, Bundle
> > and/or directly inside the URL. Not really sure what the standards do
> look
> > like in Karaf, but i bet its set in a config properties file. There you'd
> > set repositories to some local, relative folder.
> > Of cause, some initial routine needs to create/unpack that repository (it
> > will look like you .m2/repositories e.g.) initially.
> > Or you ship that in the standard karaf.zip.
> >
> > Hope that is clear?
> >
> >
> > >
> > > /Bengt
> > >
> > > 2012/2/2 Toni Menzel <to...@okidokiteam.com>
> > >
> > > > 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.
> > > > >
> > > >
> > > > correct!
> > > > 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<to...@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>
> > > >
> > >
> >
> >
> >
> > --
> > Toni Menzel Source <http://tonimenzel.com>
> >
>
--
Toni Menzel Source <http://tonimenzel.com>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Bengt Rodehav <be...@rodehav.com>.
I have been experimenting with the config.properties regarding this before
but I remember having problems preventing the normal maven way of
resolving. I'll take a look at this again.
/Bengt
2012/2/2 Toni Menzel <to...@okidokiteam.com>
> On Thu, Feb 2, 2012 at 10:03 PM, Bengt Rodehav <be...@rodehav.com> wrote:
>
> > Yes, of course there are uses for "online" mode. I hope noone believes
> that
> > I want to remove that possibility. It can even be the default as long as
> > there are ways to "lock down" Karaf. It's both a matter of "security"
> > (don't use unknown or untested code in production) and of "convenience"
> > (verify in development that the installation includes everything needed).
> >
> > @Toni
> >
> > >What you also can do is using a local, shipped with karaf maven
> repository
> > >and set that as the only one (already possible)
> >
> > I wasn't aware of this. Can you enlighten me about how this is done?
> >
>
> Well, you can always set the repositories in Pax URL via System-, Bundle
> and/or directly inside the URL. Not really sure what the standards do look
> like in Karaf, but i bet its set in a config properties file. There you'd
> set repositories to some local, relative folder.
> Of cause, some initial routine needs to create/unpack that repository (it
> will look like you .m2/repositories e.g.) initially.
> Or you ship that in the standard karaf.zip.
>
> Hope that is clear?
>
>
> >
> > /Bengt
> >
> > 2012/2/2 Toni Menzel <to...@okidokiteam.com>
> >
> > > 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.
> > > >
> > >
> > > correct!
> > > 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<to...@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<to...@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>
> > >
> >
>
>
>
> --
> Toni Menzel Source <http://tonimenzel.com>
>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Toni Menzel <to...@okidokiteam.com>.
On Thu, Feb 2, 2012 at 10:03 PM, Bengt Rodehav <be...@rodehav.com> wrote:
> Yes, of course there are uses for "online" mode. I hope noone believes that
> I want to remove that possibility. It can even be the default as long as
> there are ways to "lock down" Karaf. It's both a matter of "security"
> (don't use unknown or untested code in production) and of "convenience"
> (verify in development that the installation includes everything needed).
>
> @Toni
>
> >What you also can do is using a local, shipped with karaf maven repository
> >and set that as the only one (already possible)
>
> I wasn't aware of this. Can you enlighten me about how this is done?
>
Well, you can always set the repositories in Pax URL via System-, Bundle
and/or directly inside the URL. Not really sure what the standards do look
like in Karaf, but i bet its set in a config properties file. There you'd
set repositories to some local, relative folder.
Of cause, some initial routine needs to create/unpack that repository (it
will look like you .m2/repositories e.g.) initially.
Or you ship that in the standard karaf.zip.
Hope that is clear?
>
> /Bengt
>
> 2012/2/2 Toni Menzel <to...@okidokiteam.com>
>
> > 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.
> > >
> >
> > correct!
> > 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<to...@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<to...@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>
> >
>
--
Toni Menzel Source <http://tonimenzel.com>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Bengt Rodehav <be...@rodehav.com>.
Yes, of course there are uses for "online" mode. I hope noone believes that
I want to remove that possibility. It can even be the default as long as
there are ways to "lock down" Karaf. It's both a matter of "security"
(don't use unknown or untested code in production) and of "convenience"
(verify in development that the installation includes everything needed).
@Toni
>What you also can do is using a local, shipped with karaf maven repository
>and set that as the only one (already possible)
I wasn't aware of this. Can you enlighten me about how this is done?
/Bengt
2012/2/2 Toni Menzel <to...@okidokiteam.com>
> 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.
> >
>
> correct!
> 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<to...@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<to...@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>
>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Toni Menzel <to...@okidokiteam.com>.
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.
>
correct!
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<to...@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<to...@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>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Christian Schneider <ch...@die-schneider.net>.
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.
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<to...@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<to...@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
Re: [INFO] System repo, artifacts resolution and aether
Posted by Bengt Rodehav <be...@rodehav.com>.
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 <to...@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 <to...@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>
>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Toni Menzel <to...@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 <to...@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>
Re: [INFO] System repo, artifacts resolution and aether
Posted by Toni Menzel <to...@okidokiteam.com>.
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>