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.
Christian
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 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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
