You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2011/03/10 21:01:03 UTC
Framework roadmap
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
Re: Framework roadmap
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/10/11 15:29, David Bosschaert wrote:
> Hi Richard,
>
> On 10 March 2011 20:01, Richard S. Hall<he...@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.
> Thanks for the heads up. We're using the Felix resolver in JBoss, I'll
> look at integrating the improved version once Felix 3.2.0 is out the
> door.
There are still some "gotchas" in there, but it should be simpler than
before...we can talk if you run into issues.
-> richard
> Cheers,
>
> David
Re: Framework roadmap
Posted by David Bosschaert <da...@gmail.com>.
Hi Richard,
On 10 March 2011 20:01, Richard S. Hall <he...@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.
Thanks for the heads up. We're using the Felix resolver in JBoss, I'll
look at integrating the improved version once Felix 3.2.0 is out the
door.
Cheers,
David
Re: Framework roadmap
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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<gn...@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<he...@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
>>>>
>>>
>>>
Re: Framework roadmap
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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<gn...@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<he...@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
>>>
>>
>>
Re: Framework roadmap
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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?
-> richard
> On Fri, Mar 11, 2011 at 08:33, Guillaume Nodet<gn...@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<he...@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
>>
>
>
Re: Framework roadmap
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <gn...@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 <he...@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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Framework roadmap
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <he...@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