In addition, I'll soon start 2 discussion threads about 2 new features i'd like to introduce:
- a new resolver on way to install features / bundles using the osgi resolver the goal would be to have on a more "global" resolution when installing features, i.e. compute the needed bundles to resolve all the installed features, but still taking into account manually installed bundles. I.e. when you install a new feature, the resolver would take the features list and manually installed bundles and compute the full list of bundles to be installed. This would also allow a much better feature update mechanism. - a patch mechanism which would complement the above model but more specifically targeted at providing bug fixes i.e. not a completely new feature version, but a way to distribute micro updates of bundles (I already touched this area by introducing "overrides" in the feature installation, but we're missing the whole picture). Stay tuned ! 2014-02-25 10:57 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: > Hi all, > > In the latest weeks, we discussed about different topics and changes for > Karaf. We had very interesting different proposals, discussions, etc. > However, some discussions were on IRC, so it's not easy for everybody to > follow. > > I would like to summarise the different topics and build a roadmap. > > I gonna update the roadmap wiki page: > https://cwiki.apache.org/confluence/display/KARAF/Roadmap > > But before updating the wiki page, I would like to share with you all the > different topics and provide a global picture overview. > > 1/ Short term (3.0.x/3.1.x) > ------------- > - Fixed and enhancements on the maven-karaf-plugin. It's on my TODO for > today. It includes several fixes, add more tests, and support of Maven > 3.1/3.2 > - Usage of commons-daemon. As we are stuck to a old Tanuki JSW wrapper > (license issue), I prepared the usage of Apache commons-daemon on a branch. > I will push this branch to let you take a look. > - Samples and developer guide. I prepared a branch where I replaced the > demos modules with samples modules. The purpose is to illustrate the > developer guide (that I refactored/enhanced too) with CDI, JPA, etc samples. > - Net/minimal distributions. In addition of the "standard" distribution, > we will provide two other distributions: the net is very very minimal and > will download all artifacts from remote repository (Internet) at startup, > on the other hand, minimal distribution contains a minimal system > repository and allow to easily construct custom distribution. > - Reduce number of bundles: with Karaf 3.0.0, we introduced multiple > bundles: in Karaf itself, or due to dependency projects (like Pax URL for > instance). If I think it's good, maybe we want a bit far and, if possible, > I would reduce the number of bundles started. > - Own versioning for Spring and Enteprise Karaf Features: now, to upgrade > to new version of Spring, Hibernate, OpenJPA, etc, we have to release a new > version of Karaf. Of course, the Karaf features should be provided by the > projects themselves, but waiting this, I would like to manage Spring and > Enterprise Karaf features as "standalone". The codebase stays where it's, > but instead of depending to Karaf parent POM, it will depend directly to > Apache POM and excluded from the Karaf reactor. > > 2/ Middle term (3.1.x/future) > -------------- > - Blueprint dependency and more usage of pure OSGi/DS. Now, lot of Karaf > modules depend to blueprint (for IoC or namespace handler). In order to > minimise the footprint, and avoid some issues (like proxy), it would be > great to set Blueprint as optional and more use pure OSGi or DS internally > in Karaf. We should also provide a better "advertising" about DS support. > - Generic shell commands. Now, projects (like CXF, Camel, etc) depends to > Karaf shell modules (and console by transitivity). The purpose is: > 1/ simplify the usage/coding of commands (providing annotation especially) > 2/ avoid the dependency to blueprint (especially the namespace handler) > 3/ reduce the dependency > 4/ provide a better support of Felix Gogo shell in Karaf > > Again, the purpose of this e-mail is not to details each section, but to > provide a global picture. The details will go into the corresponding Jira. > > Thoughts ? > > Regards > JB > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
