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, 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 david 368 Jan 16 00:19 maven-metadata-nexus.xml
-rw-r--r-- 1 david david 41 Jan 16 00:19 maven-metadata-nexus.xml.sha1
-rw-r--r-- 1 david david 274 Jan 16 00:19 resolver-status.properties
-rw-r--r-- 1 david david 6575 Jan 16 00:19
spring-3.0.0-20120109.111358-15-features.xml
-rw-r--r-- 1 david david 40 Jan 16 00:19
spring-3.0.0-20120109.111358-15-features.xml.sha1
-rw-r--r-- 1 david david 6575 Jan 16 00:19 spring-3.0.0-SNAPSHOT-features.xml
I don't understand why aether would be downloading an older snapshot to replace the one
in the system repo (which it thinks is local). I also don't understand why it wouldn't
re-copy the one from the "remote" repo at ~/.m2/repository which we just built.
I think we must be missing some metadata to make aether work properly. I just
copied everything
cp
~/.m2/repository/org/apache/karaf/features/spring/maven-metadata-local.xml
apache-karaf-3.0.0-SNAPSHOT/system/org/apache/karaf/features/spring/
cp ~/.m2/repository/org/apache/karaf/features/spring/3.0.0-SNAPSHOT/*
apache-karaf-3.0.0-SNAPSHOT/system/org/apache/karaf/features/spring/3.0.0-SNAPSHOT/
and this made aether keep the correct version of the features xml.
I'm not sure what to do about this.
Is there a specification for aether? Or maybe this is an aether bug?
thanks
david jencks
On Jan 15, 2012, at 11:41 PM, Jean-Baptiste Onofré wrote:
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 features XML is overwritten and the
spring 3.0.6.RELEASE are available for install. So it means that it first goes
on the snapshot repository.
I'm fixing a couple of issues and take a look on this one.
Regards
JB
On 01/15/2012 05:44 PM, David Jencks wrote:
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 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 another machine the pax url wrap
bundle does not start similar to what you are seeing (slf4j missing).
Will keep looking...
thanks
david jencks
On Jan 14, 2012, at 10:13 AM, Jean-Baptiste Onofré wrote:
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 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
| mvn.internal.AetherBasedResolver 224 | 1 - org.ops4j.pax.url.mvn -
1.4.0.SNAPSHOT | Resolved
(org.apache.karaf.scr:org.apache.karaf.scr.feature:xml:features:3.0.0-SNAPSHOT)
as
/Users/david/projects/karaf/karaf/assemblies/apache-karaf/target/apache-karaf-3.0.0-SNAPSHOT/system/org/apache/karaf/scr/org.apache.karaf.scr.feature/3.0.0-SNAPSHOT/org.apache.karaf.scr.feature-3.0.0-SNAPSHOT-features.xml
as expected. Karaf takes about 6 seconds to start fully (first to last entry in
karaf.log). BTW last log entry is this recently reported problem:
2012-01-14 09:00:49,204 | ERROR | .features.repos) | configadmin
| ? ? | 5 -
org.apache.felix.configadmin - 1.2.8 | [org.osgi.service.cm.ManagedService,
id=149, bundle=50]: Unexpected problem updating null
java.lang.NullPointerException
at
org.apache.karaf.features.command.FeatureFinder.updated(FeatureFinder.java:46)[50:org.apache.karaf.features.command:3.0.0.SNAPSHOT]
at Proxy0946597d_464e_455e_86ae_29f5a65d3e0e.updated(Unknown Source)[:]
at
org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1160)[5:org.apache.felix.configadmin:1.2.8]
at
org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)[5:org.apache.felix.configadmin:1.2.8]
at java.lang.Thread.run(Thread.java:680)[:1.6.0_29]
without settings.xml I get an error from the "+" in
org.ops4j.pax.url.mvn.repositories= but when I remove it I get the same resolution to
system and startup takes 16 seconds. (and the same NPE).
Can you check that your local copy of pax-url-aether actually has my changes in
it? Maybe my git push got messed up somehow. My git log shows
commit 28f3b5148031d59342d3689556cfcb4b03e23477
Author: Harald Wellmann<[email protected]>
Date: Fri Jan 13 21:46:49 2012 +0100
[PAXURL-151] mvn: URL handler artifact resolution differs from Maven
resolution
Fallback repositories are now disabled by default
commit c22c2ce55671d14210d1f412b4df80048d6ef3db
Author: Harald Wellmann<[email protected]>
Date: Fri Jan 13 21:19:03 2012 +0100
[PAXURL-156] Use Pax Swissbox 1.5.0
commit 3286c3a1781830f449f56ddf45eb4b195100aeac
Author: Harald Wellmann<[email protected]>
Date: Fri Jan 13 21:10:23 2012 +0100
[PAXURL-153] Use org.ops4j.master 2.0.0 as parent
commit 9992010c896b60271612b43fe2ee26ad4ce94d00
Author: David<[email protected]>
Date: Tue Jan 10 14:05:09 2012 -0800
change version to 1.4-SNAPSHOT
commit b906c398e45431a2edd97c03bbe107ac9d531084
Author: David<[email protected]>
Date: Mon Jan 9 15:21:40 2012 -0800
PAXURL-150 Allow for default local repo to be a remote repo
commit 1745ef268cffbefea0b83623bcbeb7a5dd6de486
Author: David<[email protected]>
Date: Mon Jan 9 15:20:37 2012 -0800
PAXURL-149 Mirrors should replace the repo they mirror
commit 48955b761ac3d07205b2be626315c9193e028b33
Merge: d2a9368 427e538
Author: David<[email protected]>
Date: Sun Jan 8 10:13:28 2012 -0800
Merge branch 'master' of https://github.com/ops4j/org.ops4j.pax.url
commit d2a936858d3e01919a2efe3dc3b05da3f12c478f
Author: David<[email protected]>
Date: Sun Jan 8 10:08:54 2012 -0800
PAXURL-147 delay url handler registration until configuration is present
...
thanks
david jencks
On Jan 14, 2012, at 7:02 AM, Jean-Baptiste Onofré wrote:
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 see it with la and see the installation of the bundles and the state
change).
Regards
JB
On 01/14/2012 03:58 PM, Jean-Baptiste Onofré wrote:
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.BundleException: Unresolved constraint in bundle
org.ops4j.pax.url.wrap [2]: Unable to resolve 2.0: missing requirement
[2.0] osgi.wiring.package; (osgi.wiring.package=org.slf4j.impl))
org.osgi.framework.BundleException: Unresolved constraint in bundle
org.ops4j.pax.url.wrap [2]: Unable to resolve 2.0: missing requirement
[2.0] osgi.wiring.package; (osgi.wiring.package=org.slf4j.impl)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
I think due to the startup order as pax-logging/slf4j is not yet started
when pax.url.wrap start.
Anyway, the issue is still present with the latest pax-url.
I'm digging to find the cause.
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 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, this features XML is
overwritten by the one on Central.
I think that it's related to the latest change made by David.
I think that the order of artifact resolution should be:
1/ check in the Karaf system repository
2/ check in the user .m2/repository
3/ check in the repositories defined in the
etc/org.ops4j.pax.url.mvn.cfg
That's what I've seen happening after my changes (and never before my
changes, where it always checked remote repos first).
I wonder if you have an up to date copy of pax-url-aether? I don't
know the snapshot publishing policy at ops4j.
david jencks
I'm going to check if the ${karaf.default.repository} is correctly
used in Pax URL localRepository.
I suspect the + (prepend) could be the cause of the problem (I gonna
check).
I will give you more information later today.
More over, I saw that the demos features is present by default in the
distribution (with file: protocol). I think it should be "optional"
and provided by a demos features that the user has to reference
(add-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
--
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
