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é<[email protected]>
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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
