Thanks All for sharing these info, it gave me a global picture that without that I struggled to find.
--Filippo 2014-02-25 14:53 GMT+01:00 Christian Schneider <[email protected]>: > On 25.02.2014 14:44, Guillaume Nodet wrote: > >> 2014-02-25 13:49 GMT+01:00 Christian Schneider <[email protected]>: >> >> 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. >> > +1 > > Though even better would be to make pax url simpler so there are less > deps. But for a short term solution these bundles would help a lot. > > > >> 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). >> > +1 Makes a lot of sense. I guess they were just forgotten. > > >> 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). >> > I think we can not really hide it. Karaf ssh and the gogo webconsole > plugin also use jline (At least Terminal). > So I think the separate bundle is the least effort for us. > > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
