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

Reply via email to