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
- Framework roadmap Richard S. Hall
-
