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 <[email protected]>: > 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
