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

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
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Reply via email to