On 3/11/11 9:14, Richard S. Hall wrote:
On 3/11/11 2:35, Guillaume Nodet wrote:
Btw, the bundle is available at:
http://repo2.maven.org/maven2/org/ops4j/pax/url/pax-url-mvn/1.2.4/pax-url-mvn-1.2.4.jar
I just have to try to start this bundle to see the error?
Answering myself, yes.
Ok, I see it. I'll get to the bottom of it.
-> richard
-> richard
On Fri, Mar 11, 2011 at 08:33, Guillaume Nodet<[email protected]> wrote:
I've had a look at the resolution problem i had with 3.0.8 but now hit
a weird resolution exception on a singleton bundle:
karaf@root> osgi:start --force 1
Error executing command: Unresolved constraint in bundle
org.ops4j.pax.url.mvn [1]: Unable to resolve 1.0
karaf@root> headers 1
OPS4J Pax Url - mvn: (1)
------------------------
Manifest-Version = 1.0
Bnd-LastModified = 1294049169630
Tool = Bnd-0.0.357
Built-By = gnodet
Build-Jdk = 1.6.0_22
Created-By = Apache Maven Bundle Plugin
Bundle-Vendor = OPS4J - Open Participation Software for Java
Bundle-Activator = org.ops4j.pax.url.mvn.internal.Activator
Bundle-Name = OPS4J Pax Url - mvn:
Bundle-DocURL = http://www.ops4j.org/
Bundle-Description = OPS4J Pax Url - mvn: protocol handler.
Detailed information to be found at
http://wiki.ops4j.org/confluence/x/CoA6.
Bundle-SymbolicName = org.ops4j.pax.url.mvn; singleton:=true
Bundle-Version = 1.2.4
Bundle-License = http://www.apache.org/licenses/LICENSE-2.0.html
Bundle-ManifestVersion = 2
Import-Package =
javax.net.ssl,
javax.xml.parsers,
org.apache.commons.logging;resolution:=optional;version=1.0.4,
org.ops4j.pax.url.mvn;version=1.2.4,
org.osgi.framework;version="[1.0.0,2.0.0)",
org.osgi.service.cm;resolution:=optional;version="[1.0.0,2.0.0)",
org.osgi.service.url;version="[1.0.0,2.0.0)",
org.w3c.dom,
org.xml.sax
Export-Package =
org.ops4j.pax.url.mvn;version=1.2.4
On Thu, Mar 10, 2011 at 21:01, Richard S.
Hall<[email protected]> wrote:
A heads up...
I've committed a pretty substantial patch to the framework
resolver, which
furthers the goal of eventually making it a separate
module/subproject.
Previously, the resolver did not actually handle fragments or
singleton
bundles and instead left this up to the user of the resolver. The new
resolver handles these aspects of the OSGi resolver algorithm
internally,
thus greatly simplifying the task of the user.
At this point, I am planning on doing a framework 3.2.0 release to
get this
out in the wild as soon as possible. I'll am currently looking into
picking
off a few of the "low-hanging fruit" issues to include in the
release. This
release will still not see the resolver become its own module,
however,
since the outward facing API is likely to change substantially over
the next
couple months as a result of the new R4.3 API.
Once 3.2.0 is out the door, I am hoping to start to focus my energy on
implementing R4.3. This is likely to have substantial impact on the
framework implementation, because it introduces new concepts (like
revisions
and wirings) that more closely model existing implementation
details. I
think the best plan is to try to adopt this new API as our
implementation
API directly (where possible) rather than creating facades and
wrappers for
our existing abstractions. That'll be my initial goal, we'll see if
it is
possible.
Assuming it is, it'll mean that the next major release of the
framework will
be a little ways off into the future and quite a bit different
internally.
This likely means that once I start to commit these changes we'll
probably
have to do future 3.2.x bug fix releases from a branches off of the
3.2.x
release tags, rather than trunk. I suppose the other option is to
branch 4.0
and keep trunk as 3.2.x and replace it with 4.0 once it is done.
For me, I prefer to keep the main development in trunk, but I could be
convinced otherwise if people objected.
-> richard
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
