karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [INFO] System repo, artifacts resolution and aether
Date Thu, 02 Feb 2012 16:47:57 GMT
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
>> 


Mime
View raw message