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.
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. 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 >
