2014-02-25 11:28 GMT+01:00 Achim Nierbeck <[email protected]>: > Hi JB, > > thanks again for doing a great job to put us all in the right picture again > :) > > Now please see my comments inline: > > > 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 > > > > nice > > > > - 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. > > > > great, though I think we still could go with the "old" one, this shouldn't > be much of a blocker IMHO > > > > - 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. > > > > yeah, a net distribution sounds fair though I'm not sure it's good to > introduce this with a bugfix version. > > > > - 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. > > > > +1, need to find the balance again, I think I've said this before doing > microbundles just because we can do is not good. > > > > - 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. > > > > like this one a lot, though again I'm a bit ambivalent about this, because > doing such a "feature" change in a bug-fix version doesn't feel right. > > > > > > 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 > > > > Besides the last point I'm +1 > with 4, I just don't get why this is something Karaf does profit from. > Could the rather lengthy discussions that have taken place on IRC, and > really should have taken place on a mailinglist for all to contribute to, > please be summarized on an extra thread for this? > I still don't see the value of this. >
In my last discussion with Christian, we agreed to focus on that. The use case is to be able to leverage existing gogo commands from other projects. A first use case is the SCR commands, we did not have good support for gogo, so we ended up rewriting those commands for Karaf. While this is affordable, I think it would be better to have gogo commands better supported. The current goal is simply to provide visibility of the commands (they are hidden right now) and basic completion / description of those commands when annotated with the gogo commands. Again, the real use case is not for our commands, but to allow other OSGi related projects to be better supported in karaf when they already provide gogo commands. I don't think we can achieve the same level of features than when using karaf commands, but then it's a choice of the project to either create specific karaf commands or live with what we'll have. > > regards, Achim > > > > > > 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 > > > > > > -- > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> > Commiter & Project Lead > blog <http://notizblog.nierbeck.de/> >
