karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [PROPOSAL] Roadmap
Date Tue, 25 Feb 2014 13:10:00 GMT
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).


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é
Talend - http://www.talend.com

View raw message