karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [Discuss] Handling of initial bundles
Date Sun, 06 May 2012 22:46:18 GMT
To my concern the way main and the loading of karaf worked was "Good 
Enough for Now".
I didn't see any issues to change the way it was working. So yes if 
something is good and properly
working, don't Touch it. You might break it.

Regarding committing your changes, I do find it disturbing, that you 
start a discussion without
waiting for a result.

regards, Achim

Am 06.05.2012 22:28, schrieb Christian Schneider:
> I did not have the intention to make this more complicated. I just 
> removed the other options.
> So what exactly do you -1?
> I already committed the first step of the implementation and of course 
> did not introduce any new dependencies.
> For the next step I plan to simply read the feature file instead of 
> the properties file. I don´t think that I need the feature service for 
> that.
> Of course that means that the framework feature would only allow the 
> list of bundles and the startlevel for each bundle. So basically the same
> that is supported in the startup.properties. Is that ok?
> Christian
> Am 06.05.2012 19:12, schrieb Achim Nierbeck:
>> Even though you and Christian are certainly right that maven and OSGi 
>> work quite well if the versions are kept right, but this
>> isn't the focus here. So coming back to the initial question I agree 
>> with Guillaume, to better keep the main class
>> lean and simple therefore I give a -1 on this.
>> I don't want to see any dependencies to a features service what so 
>> ever in main.
>> Thanx, Achim
>> Am 05.05.2012 11:33, schrieb Jean-Baptiste Onofré:
>>> Agree with Christian.
>>> Leveraging Pax URL in Karaf is a key feature (even if sometime we 
>>> fake the Pax URL usage, like in startup.properties URLs).
>>> Regards
>>> JB
>>> On 05/05/2012 08:52 AM, Christian Schneider wrote:
>>>> 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
>>>>>>>>> else
>>>>>>>>> than the startup.properties.
>>>>>>>>> Regarding a feature instead of startup.properties, it
>>>>>>>>> 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").
>>>>>>>>> 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
>>>>>>>>> (like OfflineFeatureService that we use in the Karaf
>>>>>>>>> plugin).
>>>>>>>>> So it means that we will have a dual bootstrap process
which use
>>>>>>>>> feature:
>>>>>>>>> - the "startup" feature (which doesn't really use the
>>>>>>>>> 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
>>>>>>>>>> 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

- Apache Karaf<http://karaf.apache.org/>  Committer&  PMC
- OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/>    Committer&  Project
- Blog<http://notizblog.nierbeck.de/>

View raw message