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: Move bundle from framework feature (startup.properties) to a separate feature
Date Sat, 24 Mar 2012 19:44:02 GMT
While it is no big issue for you to create a custom distribution I am 
quite sure that for 99% of users it is and they will not even try.

So my argument is that people rather will start with one of the default 
karaf distros. As on the other hand users will quite for sure need more 
bundles than those in the distro - at the very least their own bundles.
So they have two options. They can either deploy to the deploy folder or 
they use maven.

For those users that use maven the network distro is ideal. They will 
load bundles from their maven repo anyway so why not load as many as 
possible and make the distro as small as possible. As the bundles will 
be cached anyway the performance effect is only relevant on first 
install. So the network distro is an ideal way for maven users to use 
karaf imho. Especially I think it is ideal for all developers as they 
will have either a maven repo or internet access quite for sure.

For distribution creation the network distro may also be intersting. We 
could provide commands to build a distro:
Like distro:create which creates a distro that contains all bundles from 
all active feature urls and all current config. So the developer could 
work with the network distro to have a small install and create a custom 
distro whenever needed.

Christian


Am 24.03.2012 19:19, schrieb Jean-Baptiste Onofré:
> Around the same topic, from a general perspective, I don't think it's 
> a good idea to provide too thin distribution.
>
> I mean that Karaf is a container, and as a container, it provides 
> standard features, and the end-user accepts that (as an end-user 
> accepts to use JEE application server even if he doesn't use all 
> features provided by the app server).
>
> The key point is to give the ability to the end user to create a 
> custom container starting from a standard distribution. That's why:
> - I'm always agree to provide simple and useful way to create custom 
> distribution (Maven plugins, etc), etc.
> - I'm most of the time against to provide new distributions. We should 
> have ONE standard distribution. The minimal (or framework) is 
> interesting to create custom distribution (so used with 
> karaf-maven-plugin) but it doesn't make sense on its own (nobody will 
> start a "production" container with minimal, an user will always 
> create its own distribution on top of minimal).
>
> If the user wants really "home made" container, he can start from the 
> framework and create its own, specific need oriented.
>
> Regards
> JB
>
> On 03/24/2012 10:58 AM, Christian Schneider wrote:
>> Hi all,
>>
>> the framework feature is used to create the startup.properties. If I
>> understood this correctly then
>> these bundles are loaded in a special way (not with pax-url). To be able
>> to create a smaller minimal distro (or an even small "network" distro)
>> I think it makes sense to have as few bundles in there as possible.
>>
>> So what has to be in there as a bare minimum. I think we need at least
>> the feature-core and pax-url with their dependencies.
>> Ist that correct? If we makes these independent of blueprint then I
>> think we can even skip the whole aries bundles.
>>
>> So I propose to create a new feature like karaf-core or similar where we
>> move all features that should always be started but that do not have to
>> be in the startup.properties.
>> Does that make sense? If yes I will create a jira and move as many
>> bundles as possible.
>>
>> So what is the benefit of moving these? If I think of the "network"
>> assembly then we can create a karaf distro that only contains the libs
>> of the startup.properties in the system
>> dir. The rest can be loaded using pax url. So I am quite sure we can
>> achieve to have a distro that is smaller than 2-3 MB.
>>
>> Christian
>>
>


-- 

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

Open Source Architect
Talend Application Integration Division http://www.talend.com


Mime
View raw message