You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2012/01/13 11:30:10 UTC
Issue with the latest mvn change on trunk
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
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
Re: Issue with the latest mvn change on trunk
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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/tests/AppTest.java
I will enhance pax-url-aether/Karaf plugins to generate the metadata and
use aether to install the artifact (in the add-features-to-repo/kar
especially).
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<ha...@gmx.de>
>>>>>> 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<ha...@gmx.de>
>>>>>> Date: Fri Jan 13 21:19:03 2012 +0100
>>>>>>
>>>>>> [PAXURL-156] Use Pax Swissbox 1.5.0
>>>>>>
>>>>>> commit 3286c3a1781830f449f56ddf45eb4b195100aeac
>>>>>> Author: Harald Wellmann<ha...@gmx.de>
>>>>>> Date: Fri Jan 13 21:10:23 2012 +0100
>>>>>>
>>>>>> [PAXURL-153] Use org.ops4j.master 2.0.0 as parent
>>>>>>
>>>>>> commit 9992010c896b60271612b43fe2ee26ad4ce94d00
>>>>>> Author: David<da...@yahoo.com>
>>>>>> Date: Tue Jan 10 14:05:09 2012 -0800
>>>>>>
>>>>>> change version to 1.4-SNAPSHOT
>>>>>>
>>>>>> commit b906c398e45431a2edd97c03bbe107ac9d531084
>>>>>> Author: David<da...@yahoo.com>
>>>>>> 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<da...@yahoo.com>
>>>>>> 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<da...@yahoo.com>
>>>>>> 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<da...@yahoo.com>
>>>>>> 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é
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Issue with the latest mvn change on trunk
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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<ha...@gmx.de>
>>>>>> 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<ha...@gmx.de>
>>>>>> Date: Fri Jan 13 21:19:03 2012 +0100
>>>>>>
>>>>>> [PAXURL-156] Use Pax Swissbox 1.5.0
>>>>>>
>>>>>> commit 3286c3a1781830f449f56ddf45eb4b195100aeac
>>>>>> Author: Harald Wellmann<ha...@gmx.de>
>>>>>> Date: Fri Jan 13 21:10:23 2012 +0100
>>>>>>
>>>>>> [PAXURL-153] Use org.ops4j.master 2.0.0 as parent
>>>>>>
>>>>>> commit 9992010c896b60271612b43fe2ee26ad4ce94d00
>>>>>> Author: David<da...@yahoo.com>
>>>>>> Date: Tue Jan 10 14:05:09 2012 -0800
>>>>>>
>>>>>> change version to 1.4-SNAPSHOT
>>>>>>
>>>>>> commit b906c398e45431a2edd97c03bbe107ac9d531084
>>>>>> Author: David<da...@yahoo.com>
>>>>>> 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<da...@yahoo.com>
>>>>>> 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<da...@yahoo.com>
>>>>>> 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<da...@yahoo.com>
>>>>>> 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é
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Issue with the latest mvn change on trunk
Posted by David Jencks <da...@yahoo.com>.
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<ha...@gmx.de>
>>>>> 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<ha...@gmx.de>
>>>>> Date: Fri Jan 13 21:19:03 2012 +0100
>>>>>
>>>>> [PAXURL-156] Use Pax Swissbox 1.5.0
>>>>>
>>>>> commit 3286c3a1781830f449f56ddf45eb4b195100aeac
>>>>> Author: Harald Wellmann<ha...@gmx.de>
>>>>> Date: Fri Jan 13 21:10:23 2012 +0100
>>>>>
>>>>> [PAXURL-153] Use org.ops4j.master 2.0.0 as parent
>>>>>
>>>>> commit 9992010c896b60271612b43fe2ee26ad4ce94d00
>>>>> Author: David<da...@yahoo.com>
>>>>> Date: Tue Jan 10 14:05:09 2012 -0800
>>>>>
>>>>> change version to 1.4-SNAPSHOT
>>>>>
>>>>> commit b906c398e45431a2edd97c03bbe107ac9d531084
>>>>> Author: David<da...@yahoo.com>
>>>>> 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<da...@yahoo.com>
>>>>> 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<da...@yahoo.com>
>>>>> 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<da...@yahoo.com>
>>>>> 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é
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Issue with the latest mvn change on trunk
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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<ha...@gmx.de>
>>>> 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<ha...@gmx.de>
>>>> Date: Fri Jan 13 21:19:03 2012 +0100
>>>>
>>>> [PAXURL-156] Use Pax Swissbox 1.5.0
>>>>
>>>> commit 3286c3a1781830f449f56ddf45eb4b195100aeac
>>>> Author: Harald Wellmann<ha...@gmx.de>
>>>> Date: Fri Jan 13 21:10:23 2012 +0100
>>>>
>>>> [PAXURL-153] Use org.ops4j.master 2.0.0 as parent
>>>>
>>>> commit 9992010c896b60271612b43fe2ee26ad4ce94d00
>>>> Author: David<da...@yahoo.com>
>>>> Date: Tue Jan 10 14:05:09 2012 -0800
>>>>
>>>> change version to 1.4-SNAPSHOT
>>>>
>>>> commit b906c398e45431a2edd97c03bbe107ac9d531084
>>>> Author: David<da...@yahoo.com>
>>>> 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<da...@yahoo.com>
>>>> 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<da...@yahoo.com>
>>>> 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<da...@yahoo.com>
>>>> 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é
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Issue with the latest mvn change on trunk
Posted by David Jencks <da...@yahoo.com>.
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<ha...@gmx.de>
>>> 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<ha...@gmx.de>
>>> Date: Fri Jan 13 21:19:03 2012 +0100
>>>
>>> [PAXURL-156] Use Pax Swissbox 1.5.0
>>>
>>> commit 3286c3a1781830f449f56ddf45eb4b195100aeac
>>> Author: Harald Wellmann<ha...@gmx.de>
>>> Date: Fri Jan 13 21:10:23 2012 +0100
>>>
>>> [PAXURL-153] Use org.ops4j.master 2.0.0 as parent
>>>
>>> commit 9992010c896b60271612b43fe2ee26ad4ce94d00
>>> Author: David<da...@yahoo.com>
>>> Date: Tue Jan 10 14:05:09 2012 -0800
>>>
>>> change version to 1.4-SNAPSHOT
>>>
>>> commit b906c398e45431a2edd97c03bbe107ac9d531084
>>> Author: David<da...@yahoo.com>
>>> 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<da...@yahoo.com>
>>> 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<da...@yahoo.com>
>>> 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<da...@yahoo.com>
>>> 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é
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
Re: Issue with the latest mvn change on trunk
Posted by David Jencks <da...@yahoo.com>.
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<ha...@gmx.de>
>> 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<ha...@gmx.de>
>> Date: Fri Jan 13 21:19:03 2012 +0100
>>
>> [PAXURL-156] Use Pax Swissbox 1.5.0
>>
>> commit 3286c3a1781830f449f56ddf45eb4b195100aeac
>> Author: Harald Wellmann<ha...@gmx.de>
>> Date: Fri Jan 13 21:10:23 2012 +0100
>>
>> [PAXURL-153] Use org.ops4j.master 2.0.0 as parent
>>
>> commit 9992010c896b60271612b43fe2ee26ad4ce94d00
>> Author: David<da...@yahoo.com>
>> Date: Tue Jan 10 14:05:09 2012 -0800
>>
>> change version to 1.4-SNAPSHOT
>>
>> commit b906c398e45431a2edd97c03bbe107ac9d531084
>> Author: David<da...@yahoo.com>
>> 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<da...@yahoo.com>
>> 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<da...@yahoo.com>
>> 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<da...@yahoo.com>
>> 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é
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Issue with the latest mvn change on trunk
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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<ha...@gmx.de>
> 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<ha...@gmx.de>
> Date: Fri Jan 13 21:19:03 2012 +0100
>
> [PAXURL-156] Use Pax Swissbox 1.5.0
>
> commit 3286c3a1781830f449f56ddf45eb4b195100aeac
> Author: Harald Wellmann<ha...@gmx.de>
> Date: Fri Jan 13 21:10:23 2012 +0100
>
> [PAXURL-153] Use org.ops4j.master 2.0.0 as parent
>
> commit 9992010c896b60271612b43fe2ee26ad4ce94d00
> Author: David<da...@yahoo.com>
> Date: Tue Jan 10 14:05:09 2012 -0800
>
> change version to 1.4-SNAPSHOT
>
> commit b906c398e45431a2edd97c03bbe107ac9d531084
> Author: David<da...@yahoo.com>
> 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<da...@yahoo.com>
> 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<da...@yahoo.com>
> 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<da...@yahoo.com>
> 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é
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Issue with the latest mvn change on trunk
Posted by David Jencks <da...@yahoo.com>.
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 <ha...@gmx.de>
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 <ha...@gmx.de>
Date: Fri Jan 13 21:19:03 2012 +0100
[PAXURL-156] Use Pax Swissbox 1.5.0
commit 3286c3a1781830f449f56ddf45eb4b195100aeac
Author: Harald Wellmann <ha...@gmx.de>
Date: Fri Jan 13 21:10:23 2012 +0100
[PAXURL-153] Use org.ops4j.master 2.0.0 as parent
commit 9992010c896b60271612b43fe2ee26ad4ce94d00
Author: David <da...@yahoo.com>
Date: Tue Jan 10 14:05:09 2012 -0800
change version to 1.4-SNAPSHOT
commit b906c398e45431a2edd97c03bbe107ac9d531084
Author: David <da...@yahoo.com>
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 <da...@yahoo.com>
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 <da...@yahoo.com>
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 <da...@yahoo.com>
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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: Issue with the latest mvn change on trunk
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Issue with the latest mvn change on trunk
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Issue with the latest mvn change on trunk
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Issue with the latest mvn change on trunk
Posted by David Jencks <da...@yahoo.com>.
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
>
>
>
>