karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [Discuss] Handling of initial bundles
Date Fri, 04 May 2012 18:35:03 GMT
It makes sense, and I don't want to use the OfflineFeatureService (not 
require) but we will certainly have to decide to some "restriction" (for 
instance, what do we do if a feature is define in a feature ;)).


On 05/04/2012 08:18 PM, Christian Schneider wrote:
> Hi JB,
> yes we do not use the real maven resolution. I thought about changing it
> but it would have too many dependencies.
> I did not mean to really use features. Rather to read the feature file
> instead of the startup.properties but still process and resolve in the
> same way as before. So this should not add
> much complexity. We could use the OfflineFeatureService but I dont think
> it is really necessary.
> Christian
> Am 04.05.2012 19:24, schrieb Jean-Baptiste Onofré:
>> Hi,
>> As reminder, in startup properties we don't really use mvn URL. I mean
>> we construct a file URL from the mvn one, we don't really use Pax URL.
>> Anyway, it sounds good to me. I don't think users use anything else
>> than the startup.properties.
>> Regarding a feature instead of startup.properties, it means that we
>> have to load at least feature core. I'm not sure that it's a good idea
>> because feature is already OSGi oriented, whereas in the main area we
>> start the framework (so we are not in the "OSGi area"). It's possible
>> but it means that even if we provide a features XML, it's not really
>> the feature service that will be use but a FeatureStartup process
>> (like OfflineFeatureService that we use in the Karaf maven plugin).
>> So it means that we will have a dual bootstrap process which use feature:
>> - the "startup" feature (which doesn't really use the feature service)
>> - the "boot" feature (which uses the feature service)
>> As the startup.properties is generated from a feature currently, it
>> makes sense to directly use the feature.
>> All depends the way that it will be implemented, but basically +1
>> Regards
>> JB
>> On 05/04/2012 07:03 PM, Christian Schneider wrote:
>>> 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

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message