+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
