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 12:49:28 GMT
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

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message