Just a few comments to explain what I've (am) working on... 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. > Thx a lot ! > > 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. > Is commons-daemon now on par with wrapper ? i must admit i haven't looked in a few years .... - 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. > I'm currently working on pax-url to provide uber-bundles which we'll be able to integrate instead of dragging a dozen of bundles. I'm also re-integrating gogo into shell/console (the split I did back in december was not actually really good and kept lots of duplicated packages). And also jansi which is already provided by the jline bundle. With those 3 modifications, i'm currently down to 37 bundles ... > - 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. > I'm a bit skeptical on that. We actually do release Karaf quite often, so i'm not sure it will actually bring much... > > 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. > I have a branch which works without blueprint at all. I don't really want to push it now to asf because I'm rebasing from time to time on master, and I don't think the asf allows forced push. But if that's the case, I'd be happy to push it so that people can have a look. It's not entirely finished as we'd have to take care about the features definition and distribution. > - 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 > This is something Christian and I are working on. Master already contains support for SCR based commands, and the blueprint namespace has been enhanced to mostly get rid of all the declaration. Most of the command definitions now look very simple: https://github.com/apache/karaf/blob/master/config/command/src/main/resources/OSGI-INF/blueprint/shell-config.xml Also, the SCR support is not completely finished as we're still missing subshell when using SCR powered commands. > > 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 >
