karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [Discuss] Handling of initial bundles
Date Sat, 05 May 2012 06:52:00 GMT
Well in this case you should use felix it uses a flat list of bundles :-)

I think the maven centric aproach is the biggest benefit in karaf. Of 
course obr can help to make this even better but out there you almost 
find no obr repos.
The big benefit with maven is that you have almost any lib available. 
You only need to know the artifact coordinates. For example it is great 
that you can install cxf or camle by just
issuing two commands. How should that work without features that load 
artifacts from maven?  As soon as all bundles are available in obr repos 
we can switch to this aproach but
I think that is not the near future.

I think the aproach of installing features and bundles from a company 
maven repo should be our recommended way of installing applications. I 
recommend to companies to split
their development and deployment process at the maven repo. Developers 
build the sources and deploy the binaries to the company maven repo. 
Admins install from there. I think
that is the cleanest technical aproach to devops we currently have.
Of course this should include the use of the obr. As obr and maven often 
are incorporated in the same repository (like nexus or archiva) this 
should be achievable.

Kar files are a dead end for me. They have their purpose when companies 
do not have a repository but they are completely anti modular. If you 
deploy two applications using kar files you have a lot of duplication
and most of the advantages of osgi are gone.

About the flar system repo. Why should that be a good idea? The good 
thing about the system repo as a maven repo is that it mimics the 
central repo. So users can be sure that our system repo is just a cache.
All the artifacts in there are the same as in central. So the user knows 
that each of these jars is the "official" version. This is very helpful 
for example for doing licensing audits.

Btw. I think maven and osgi are very compatible on the lowest level. 
Maven can supply single artifacts very well. It is only the dependency 
resolution that is not compatible but obr can help out with that.

Christian

Am 05.05.2012 04:04, schrieb David Jencks:
> I think we should make karaf much less maven centric including:
>
> -- system repo is flat, not maven structured, with file names enforced as bundle-symbolic-name_bundle-version.jar.
 startup.properties can then just have jar-name=start-level.
>
> -- kar files use similar flat internal repo
>
> -- non-kar features deprecated
>
> -- heavily encourage use of obr.
>
> maven and osgi are really not very compatible and trying to pretend they are IMO leads
to too many problems and suppresses the usefulness of osgi.
>
> thanks
> david jencks
>
> On May 4, 2012, at 12:46 PM, Guillaume Nodet wrote:
>
>> Please, keep the main file lean and simple, no dependencies on url handlers
>> or features or OBR or anything.
>> The less interactions we have with the framework, the less fixes we'll to
>> do there and the more stable it will be.
>> The idea is to bootstrap the osgi framework, all the real provisioning
>> should be done in the osgi framework itself using the feature service or
>> obr or anything else that is required.
>>
>> On Fri, May 4, 2012 at 8:35 PM, Jean-Baptiste Onofré<jb@nanthrax.net>wrote:
>>
>>> 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 ;)).
>>>
>>> Regards
>>> JB
>>>
>>>
>>> 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é
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>> -- 
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Mime
View raw message