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 07:01:29 GMT
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 early.
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 
- 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
- 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

- 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

- 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


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

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

View raw message