Confirmed with olamy: without the metadata, aether will overwrite the
local artifact (especially for SNAPSHOT).
The following test shows how to use aether API to install the artifact
and generate the metadata:
https://github.com/olamy/archiva-tests/blob/master/src/test/java/org/olamy/archiva/t
Agree, it's my conclusion too about the behavior.
I'm reviewing pax-url and aether with olamy to check it. I will provide
an update soon ;)
Regards
JB
On 01/16/2012 09:48 AM, David Jencks wrote:
OK, I'm seeing that too. Aether is definitely treating the karaf system repo
as the local repo,
OK, I'm seeing that too. Aether is definitely treating the karaf system repo
as the local repo, since it's putting a bunch of metadata files in there to
show what it did:
ls -l
apache-karaf-3.0.0-SNAPSHOT/system/org/apache/karaf/features/spring/3.0.0-SNAPSHOT/
total 64
-rw-r--r-- 1 david da
Hi David,
even without the prepend (+) in the configuration file (your latest
commit), the issue is still present.
If you check the spring features XML in the system repo, it's correct
(containing the 3.1.0.RELEASE spring features), but when you type
features:list-url + features:list, the fe
I think the remaining issue here (unsatisfied wiring constratnt to
(osgi.wiring.package=org.slf4j.impl))) means someone broke pax-url-wrap since
that package isn't exported at all by the pax-logging bundles.
thanks
david jencks
On Jan 14, 2012, at 2:19 PM, David Jencks wrote:
> When I removed
When I removed settings.xml (with mirror settings) I found the syntax of the
mvn repo list was wrong and only the startup bundles would start. I committed
a fix. Now (almost) all the bundles start for me and aether is using the karaf
system repo.
On my dev machine all the bundles start. On a
It's what I did:
- git clone && mvn clean install -DskipTests on ops4j base, swissbox, url
- mvn clean install -DskipTests on Karaf
on two different environments, same behavior.
I'm performing new tests/builds and keep you posted.
Regards
JB
On 01/14/2012 06:15 PM, David Jencks wrote:
I track
I tracked down all the snapshots now needed for pax url and built
base
swissbox
url
karaf
With settings.xml in place using local nexus as a mirror I don't see that
exception and karaf.log shows entries like
2012-01-14 09:00:44,943 | INFO | rint Extender: 3 | AetherBasedResolver
|
Another issue that we have to address is the startup time.
Karaf 2.2.x is very quick to start (something like 5 seconds on my
machine), whereas Karaf 3.0.0 is very long (I got the shell in around 5
seconds, but to have all services available (features, etc), it takes
something like 1mn, we can
Hi David,
I built Pax URL 1.4-SNAPSHOT on my machine (with a fresh git pull).
And I have exactly the same issue. Moreover I have another issue at startup:
ERROR: Bundle org.ops4j.pax.url.wrap [2] Error starting
mvn:org.ops4j.pax.url/pax-url-wrap/1.4-SNAPSHOT
(org.osgi.framework.BundleExceptio
Hi David,
I'm trying with a locally built pax-url-aether (and I will publish a
snapshot on oss).
I will keep you posted.
Regards
JB
On 01/13/2012 07:37 PM, David Jencks wrote:
On Jan 13, 2012, at 2:30 AM, Jean-Baptiste Onofré wrote:
Hi all,
I saw an issue while updating the Spring versi
On Jan 13, 2012, at 2:30 AM, Jean-Baptiste Onofré wrote:
> Hi all,
>
> I saw an issue while updating the Spring version in Karaf 3.0.0-SNAPSHOT.
>
> It seems that now, Karaf goes on Central first, before cheking in the Karaf
> system repository.
>
> For instance, the Karaf Spring features XML
Hi all,
I saw an issue while updating the Spring version in Karaf 3.0.0-SNAPSHOT.
It seems that now, Karaf goes on Central first, before cheking in the Karaf
system repository.
For instance, the Karaf Spring features XML is correct in the system repo, but
after performed a features:list-url, t
13 matches
Mail list logo
