2014-02-25 13:49 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
> Hi Guillaume, > > some questions and comments inline. > > > On 25.02.2014 11:14, Guillaume Nodet wrote: > >> 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 ... >> > Can you provide some details about the uber bundles? Which of these > bundles would we have an what would they contain? > The goal is simply to have pax-url-aether, pax-url-wrap and pax-url-war being standalone bundles. That was the case before 1.4.0 and I aim to provide 2 bundles for those so that people can choose to use smaller ones or standalone ones. > About shell console. As far as I can see gogo is already integrated inside > shell.console. I think we embed the packages. > Regarding jline I would like to keep jline separate as it has native code > in it which made packaging of shell console a bit more challenging. > I am pretty happy about the current granularity of shell.console.Having > jline separate also shields us from internal packaging details of jline > which > might change between versions. What I meant is that gogo-runtime and jansi are installed as bundles but those are duplicate packages because they are already provided respectively by shell.console and jline. The only real thing to do is to remove them from the framework kar (and reference the activator in shell/console). For jline, i'm not sure. In 2.x is was inlined in shell.console and it has been split apart in 3.x. Ideally, it would be hidden and embedded as that's a console implementation detail and should not be leaked outside. Unfortunately, we have a few dependencies on it, so I'm not sure we can actually hide it, in which case, I'd keep the current packaging. The main bundle which would cause problems if we were to inline and hide jline would be jledit which has strong ties to jline. I think the other uses we have could be mostly refactored, but in all cases, having a cleaner api for the console would be good, it could just be a wrapper around jline Terminal, which is the main (and only ?) class actually used (outside the console). > > 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. >> > Great to hear you are as far already. I think it would be great to have a > look on this. > From my point of view I would like to see the DS migration rather earlier > than later. > As it is just an internal change I think technically we could deliver it > in any 3.x (minor) release. > I know this is currently planned for 4.0 but perhaps we can rethink this > if the DS version of karaf is stable and compatible. > > Best regards > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
