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
