[DISCUSS] Profiles

[Łukasz Dywicki <lu...@code-house.org>]

Hi all,
In topic "Generate assembly of Apache Karaf" we have proposition of profiles
for Karaf. I talked about this some time ago on irc channel and would like
back to get some real shape of this idea.

First problem which we have is difference between build time and execution
time. I think that we have three different things: 
- platform assembly (android, pc, some other)
- branding stuff (splash screen, boot features, features, configurations,
bundles)
- Instances (features, boot features, configurations, bundles)

First two things are strictly related to maven assembly, but not fully.
These two things have to be done during build time (including splash screen)
but rest elements may be simply cut out from build and moved to profile
which is portable and platform/brand independent.

Branding stuff comes to real pain when we clone Karaf/product instance with
admin:create command. It may copy base configuration files but won't copy
any user stuff. They have to copy it by hand.

To make profile extremely useful for our users we may allow inheriting
things from other profiles to allow portability and extendibility. For
example we may have minimal, standard, web and enterprise profile.
ServiceMix may come with nmr profile which is an extension of enterprise and
messaging profile (from activemq). The jbi is extension of nmr with few
additional boot features and configuration files.

Boot features and feature configuration is brilliant idea. However It's just
not enough. It still won't be copied or managed by Karaf's administration
stuff. What afraid me is that we'll have different places where
configuration may be stored - for example in feature descriptor and profile
definition. But do we have to define feature to create configuration file?
What do you think about this.

Do we need profiles? We simply don't need unnecessary abstraction layer
build on top of features but Karaf admin service is a bit messy with tires
of copying resources. Who don't believe please check
AdminServiceImpl#createInstance. We have also different things related to
branding like file renaming (eg. karaf.bat -> servicemix.bat) and
environment variables like KARAF_DEBUG -> SERVICEMIX_DEBUG which may be
changeable. Users which tries to create own profile don't have to be Java
masters with maven assembly descriptor knowledge. It might be just system
admin which want's to manage bigger number of instances.

Best regards,
Lukasz

Re: [DISCUSS] Profiles

[Guillaume Nodet <gn...@gmail.com>]

I think djencks has set a good path to make all those things easier to
use by leveraging features and kars.
A custom karaf distribution can be simply created by having a maven
pom and referencing the required kars as dependencies.
As kars can themselves have dependencies on other kars, you end up
with a nice tree of required kars, I think a profile can be simply
seen as one kar with other dependencies.

As for the admin service, currently it mostly creates a new bare karaf
instance with a set of additional features to install.
I agree this is not sufficient, and we should have a way to have a
list of kars/features that will always be installed and an easy way to
specify on the command line a list of kars to install.

Before going wild in any direction, I want to make sure everyone fully
understand the changes on features / kars, as they will now be maven
packaging, and we'll have a nice leverage on maven dependencies
through those.

2011/1/24 Łukasz Dywicki <lu...@code-house.org>:
> Hi all,
> In topic "Generate assembly of Apache Karaf" we have proposition of profiles
> for Karaf. I talked about this some time ago on irc channel and would like
> back to get some real shape of this idea.
>
> First problem which we have is difference between build time and execution
> time. I think that we have three different things:
> - platform assembly (android, pc, some other)
> - branding stuff (splash screen, boot features, features, configurations,
> bundles)
> - Instances (features, boot features, configurations, bundles)
>
> First two things are strictly related to maven assembly, but not fully.
> These two things have to be done during build time (including splash screen)
> but rest elements may be simply cut out from build and moved to profile
> which is portable and platform/brand independent.
>
> Branding stuff comes to real pain when we clone Karaf/product instance with
> admin:create command. It may copy base configuration files but won't copy
> any user stuff. They have to copy it by hand.
>
> To make profile extremely useful for our users we may allow inheriting
> things from other profiles to allow portability and extendibility. For
> example we may have minimal, standard, web and enterprise profile.
> ServiceMix may come with nmr profile which is an extension of enterprise and
> messaging profile (from activemq). The jbi is extension of nmr with few
> additional boot features and configuration files.
>
> Boot features and feature configuration is brilliant idea. However It's just
> not enough. It still won't be copied or managed by Karaf's administration
> stuff. What afraid me is that we'll have different places where
> configuration may be stored - for example in feature descriptor and profile
> definition. But do we have to define feature to create configuration file?
> What do you think about this.
>
> Do we need profiles? We simply don't need unnecessary abstraction layer
> build on top of features but Karaf admin service is a bit messy with tires
> of copying resources. Who don't believe please check
> AdminServiceImpl#createInstance. We have also different things related to
> branding like file renaming (eg. karaf.bat -> servicemix.bat) and
> environment variables like KARAF_DEBUG -> SERVICEMIX_DEBUG which may be
> changeable. Users which tries to create own profile don't have to be Java
> masters with maven assembly descriptor knowledge. It might be just system
> admin which want's to manage bigger number of instances.
>
> Best regards,
> Lukasz
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com