Hi guys,
some comments:
1/ I will take a look on Guillaume's changes about Pax URL. I think it's
good to embed some part. For instance, pax-url-wrap required to install
bndTool, swissbox, tinybundle, etc (AFAIR): we can just embed the
necessary in the Pax URL bundles.
2/ Yes and no for gogo.shell. AFAIR, we "duplicated" the gogo shell code
(at a previous point). We provide directly org.apache.felix.gogo*
packages (but it doesn't come from the gogo artifact).
Agree for jline.
3/ I agree with Christian about DS, but not necessary for commands. As I
proposed in the previous e-mail, leveraging more pure OSGi and DS is
something that we can start. I started to refactore some modules on a
local branch to avoid usage of blueprint (based on master).
Regards
JB
On 02/25/2014 01:49 PM, Christian Schneider wrote:
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?
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.
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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
