Note that I've recently enhanced the startup mecahnism to not *always* try to install the bundles listed in the startup.properties. Previously, they were always reinstalled at startup time.
First, I don't really see the need for local-repo and system. I think we should just merge them. There's really no need for bootFeatures + startupFeatures. I think we should only have one mechanism. The original idea was that the core bundles are started with the startup.properties and everthing else installed using features, mostly through bootFeatures. Now that we have a better maven plugin, the plugin is able to do both, but this is a bit confusing. Note that there is some differences though: * bundles listed startup.properties have to be in the system repo as the real mvn url handlers can't be used * manually editing the statup.properties is much more tedious than changing the bootFeatures imho * you can't put bundles using wrap url handler in the startup.properties The third point is specially problematic I think. One possible use case that isn't really addressed yet is the ability to create a configuration where some features depend on url handlers that are provisioned by other features. Or, said another way, a feature can only be *installed* if a dependent feature is *started*. I think moving things back in the startup.properties will make such dependencies even harder to manage. I think I would have rathe gone the opposite direction and remove as much as possible from the startup.properties to use the bootfeatures instead, but it may be just me. Just to understand the goal, what kind of benefit do you see by listing all bundles in the startup.properties ? I suppose we could get rid of the features service at runtime then, but apart from that, I'm not sure to see. On Sun, Apr 17, 2011 at 09:41, David Jencks <[email protected]> wrote: > Well, I think it may promote confusion, but there are now 3 options for > features in features repositories of maven runtime scope: > > startupFeatures. The bundles in these features will get installed into > system and listed in startup.properties > > bootFeatures: The bundles in these features will get installed into > local-repo and the feature names added to bootFeatures in the features cfg > file > > installedFeatures: The bundles in these features will get installed into > local-repo. > > For instance, > > <configuration> > <startupFeatures> > <feature>ssh</feature> > <feature>config</feature> > <feature>management</feature> > </startupFeatures> > </configuration> > > Note that except for startupFeatures the bundles are installed into > local-repo. I think system should only have bundles started from > startup.properties in it. > > thoughts? > > thanks > david jencks > > On Apr 16, 2011, at 12:50 PM, Johan Edstrom wrote: > >> For me it'd be the same logic as not "starting" everything from tomcats >> endorsed lib and >> just deploying WAR file, perhaps a little convoluted comparison, but the >> features additions, adding >> things and keeping "application" vs. features does make it simpler to manage >> as your features and deployments grow. >> >> >> On Apr 16, 2011, at 1:05 PM, David Jencks wrote: >> >>> If the same bundles all get started when you start the server, what is the >>> difference? I think you've "designed" the server you want by including the >>> bundles and indicating that you want them started at server startup. How >>> is it different whether the bundles are started from startup.properties or >>> the feature service looking at boot features? >>> >>> thanks >>> david jencks >>> >>> On Apr 16, 2011, at 11:48 AM, Johan Edstrom wrote: >>> >>>> I really think that the startup.properties is for infrastructure, >>>> bluperint etc. >>>> the startup features allows you do "design" your own distro. >>>> >>>> >>>> On Apr 16, 2011, at 12:42 PM, David Jencks wrote: >>>> >>>>> Hi JB, >>>>> >>>>> Thanks for the explanation, I think I've looked at things from only the >>>>> karaf-assembly point of view too long to see anything else :-) The way >>>>> karaf-assembly works now, all the bundles in system will be listed in >>>>> startup.properties and will start automatically. >>>>> >>>>> I think you are saying: >>>>> >>>>> -- if you include a feature in the boot feature list, you should make >>>>> sure all the bundles needed are in the server already. >>>>> >>>>> and, looking more closely at the add-features-to-repo mojo I see there's >>>>> a <features> configuration element that lets you specify features to >>>>> install the bundles for. >>>>> >>>>> I'm going to add that capability to the karaf-assembly packaging. >>>>> >>>>> There's another difference of style to resolve. I've set up the >>>>> karaf-assembly packaging so that whenever it installs a featue, it adds >>>>> the feature's bundles to startup.properties at the appropriate start >>>>> level. For "boot" features this means that you don't need to list them >>>>> in the features service configuration "boot features" since they will be >>>>> started via the startup.properties. On the other hand you can't >>>>> uninstall this feature so easily. Is this an important difference? Do I >>>>> need to make a way to install a feature's bundles but not add the bundles >>>>> to startup.properties? >>>>> >>>>> many thanks >>>>> david jencks >>>>> >>>>> >>>>> On Apr 16, 2011, at 12:12 AM, Jean-Baptiste Onofré wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> I'm not sure to follow you. bootFeatures property defines which features >>>>>> are started at Karaf bootstrap time. It allows user to start a fresh >>>>>> Karaf instance with a set of Karaf features loaded and installed. >>>>>> >>>>>> For instance, in ServiceMix, we have: >>>>>> - nmr feature as boot feature and we ship all required jar (using >>>>>> features-add-to-repo goal) in the system OBR >>>>>> - camel-nmr, cxf-nmr, etc are part of the NMR features but not in the >>>>>> boot features set. As we consider this kind of features as optional, we >>>>>> don't ship the features jar in the system OBR >>>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>> On 04/16/2011 08:32 AM, David Jencks wrote: >>>>>>> I am wondering why we have boot features in trunk. In particular I >>>>>>> think there is an inconsistency around the management feature which is >>>>>>> in the minimal boot feature list and whose jars are in the minimal >>>>>>> server assembly. On the other hand the ssh full boot feature doesn't >>>>>>> have all its jars in the full server. >>>>>>> >>>>>>> If a boot feature doesn't already have all its jars in the server, >>>>>>> won't this require internet access on initial startup? >>>>>>> >>>>>>> If all the jars for a boot feature are already installed in the server, >>>>>>> why call it a boot feature, why not just start it with the rest of the >>>>>>> jars? For this question I may be biased by looking at the packaging >>>>>>> based assemblies where the startup.properties is constructed from the >>>>>>> features that are installed into the server, so it is at least as east >>>>>>> to configure the assembly to just include the jars as to configure a >>>>>>> boot feature. >>>>>>> >>>>>>> Am I missing something? >>>>>>> >>>>>>> thanks >>>>>>> david jencks >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com Connect at CamelOne May 24-26 The Open Source Integration Conference http://camelone.com/
