Christian:
I am curious
1) are your changes are in current karaf 3 snapshot?
2) do you have example/test project that shows how to build
karaf distro w/o startup.properties, with minimal feature=framework
only?
3) or is the idea discarded?
Thank you,
Andrei
-------- Original Message --------
Subject: Re: [Discuss] Handling of initial bundles
From: Christian Schneider <[email protected]>
To: [email protected]
Date: Tue 08 May 2012 11:26:49 AM CDT
>
>
> 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
>>>
>
>
