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
