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: [Discuss] Handling of initial bundles
Date Tue, 08 May 2012 16:26:49 GMT

Am 08.05.2012 17:49, schrieb David Jencks:
> I really don't understand what problem you are trying to solve.  Most people won't use
a custom assembly or if they do will use the same startup.properties as our assemblies.  Anyone
who needs to construct a custom set of startup bundles isn't going to be worried by the startup.properties
format, that is a tiny detail compared with figuring out what you need to get a working server
from startup bundles.
The advantage is that we do not need the extra step to create the 
startup.properties. The advantage is small though. So if there is a 
majority for not implementing the feature
reading I will not do it.
> I agree with Guillaume that keeping the startup code simple is a very high priority.
 To me, adding anything that involves xml to the startup code is a really bad idea and would
require very clear and overwhelming advantages to be considered.
> I've never suggested reading more than one feature during startup.  I think the current
approach of generating startup.properties from features specified in the assembly's pom is
just fine.
That is what I meant. That you wrote we need to be able to combine 
several features into startup.properties. If we would do this with pure 
features it would mean that we need to be able to use more than one feature.

> thanks
> david jencks
> On May 8, 2012, at 12:01 AM, Christian Schneider wrote:
>> I would like to summarize the discussion about my proposed second step to replace
the startup.properties by a feature loading. Again sorry that I committed the first part too
>> I think though that our discussion mainly was about the second part and I did not
even start to implement that.
>> Here the requirements people wrote during the discussion:
>> - We should not introduce additional dependencies into the main module
>> - Some people like the startup.properties. So we should keep this feature
>> - In addition to the maven urls we should also support loading bundles from a flat
directory structure
>> - We should allow several features from several feature files to be used at startup
>> So this is what I propose to fullfill the above requirements:
>> - If a startup.properties file exists then the bundles in there will be loaded and
started (works already)
>> - We introduce two new optional properties for config.properties: startup.feature.url
and startup.feature.name (default:framework)
>> - If the startup.feature.url property is present then we resolve the startup.feature.url
using the ArtifactResolver and read the named feature. We then install all bundles in the
>> feature with their corresponding startlevels
>> - We allow to use file names in the startup.properties that are searched in system
and bundle.locations. This allows the flat structure. (Works already)
>> - We read the feature file using jaxb but not with the feaure service. Instead we
simply use annotated pojos
>> - We switch the build process of our framework feature to not generate the startup.properties
anymore and instead use the new properties to reference the existing
>> feature
>> - I propose to not implement the possibility to use more than one feature in the
startup as this feature is only used to bootstrap the distro. I dont think custom distros
need to change that behaviour
>> Pro:
>> - Makes our build simpler
>> - Makes our itests simpler as we do not need to sync the startup.properties anymore
by hand
>> - People who already know the feature concept do not have to learn the new concept
of the startup.properties
>> Con:
>> - We have an additional description of a feature file in main. I think this is not
so bad as we keep it to the minimum. We should also detect discrepancies very fast as the
>> itests will fail
>> Christian
>> Am 04.05.2012 19:03, schrieb Christian Schneider:
>>> Hi all,
>>> on startup we currently use the following procedure.
>>> We read property karaf.auto.start from the file config.properties.
>>> This can be either a list of bundles separated by spaces or "startup.properties"
or "all".
>>> If it is all we replace karaf.auto.start with the list of all bundles in the
system dir. I think this option does not really make much sense.
>>> If it is startup.properties then we replace karaf.auto.start with the list of
bundles specified in the file startup.properties.
>>> Additionally we either support mvn urls or paths which are converted to mvn urls.
>>> This all is quite a lot of variability of which we use none.
>>> I propose to replace this in two steps:
>>> 1. Remove the karaf.auto.start property and always load the bundles from startup.properties.
Also only support mvn urls.
>>> This makes the code in main cleaner and makes it easier for our users to understand
how to change the startup bundles.
>>> 2. Remove the startup.properties and instead use a feature name to determine
the list of bundles to load
>>> The second step makes this even simpler and additionally we can remove the generation
of the startup.properties in the karaf maven plugin.
>>> So what do you think?
>>> Christian
>> -- 
>> Christian Schneider
>> http://www.liquid-reality.de
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com

Christian Schneider

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

View raw message