karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [Discuss] Handling of initial bundles
Date Tue, 08 May 2012 07:46:09 GMT
The problem for me is not too many dependencies, it is really too much
code.  The more code there is in main, the more bug fixes there will be,
which means that people won't be able to update at runtime.
What I really don't like in bringing features is that those have changed in
the past and may certainly also change in the future, which mean the main
jar will not be as stable is it should be.
I really prefer to keep it at a minimum and rely on the feature service to
deploy all the features.  Why is that a problem ?

On Tue, May 8, 2012 at 9:01 AM, Christian Schneider <chris@die-schneider.net
> 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 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
> 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

Guillaume Nodet
Blog: http://gnodet.blogspot.com/
FuseSource, Integration everywhere

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message