felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Framework roadmap
Date Fri, 11 Mar 2011 14:46:26 GMT
Ok, it is fixed in trunk now. Just a silly bug.

-> richard

On 3/11/11 9:16, Richard S. Hall wrote:
> 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<gnodet@gmail.com>  
>>> 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<heavy@ungoverned.org>  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
>>>>
>>>
>>>

Mime
View raw message