karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [PROPOSAL] Roadmap
Date Tue, 25 Feb 2014 13:53:20 GMT
On 25.02.2014 14:44, Guillaume Nodet wrote:
> 2014-02-25 13:49 GMT+01:00 Christian Schneider <chris@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.

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 Schneider

Open Source Architect

View raw message