+1 Achim. If one feels that they should start a discussion on the ML over a proposed change, than its best to wait for the outcome of the discussion before checking it in. If the code needs to be available for ML review than please create a JIRA, and upload a patch or make a git copy available.
Cheers, Jamie On Sun, May 6, 2012 at 8:16 PM, Achim Nierbeck <[email protected]> wrote: > 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é<[email protected]>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é >>>>>>>> [email protected] >>>>>>>> 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 Lead > - Blog<http://notizblog.nierbeck.de/> >
