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
