Christian, I don't care about the fact that the main class is 3000 lines or split into 30 files of 100 lines each. What I care about is that the main jar is so simple so we don't ever have to touch it. The main reason is that while you can update all the bundles in the osgi framework, if you have to change the main jar, you need a manual intervention. So the less code we have in main the better. This implies that we don't handle features or OBR there and this also implies that we should not try to do a real maven resolution here too (but that's not the case right now afaik).
As for simplifying the startup.properties and config.properties handling, that sounds like a good idea. The original code comes from Felix directly and only had minor modifications to do what we want, but some features are clearly not used. On Mon, May 7, 2012 at 8:18 AM, Christian Schneider <[email protected] > wrote: > I waited for almost 2 days. Your mail came just shortly after my commit. > So I thought the dicussion was settled. > You are right though that I could have waited a little longer. I only > committed the first part though and I think that I incorporated all > feedback into the change. > > So let me summarize the feedback and how I included it: > > - There was only positive feedback about having only the > startup.properties and not the properties in the config.properties to > control the startup bundles. So I think we agreed on this. > - David gave the feedback that he would like the startup.properties to be > a flat list of bundles. While I don´t agree that this is a good idea this > is absolutely possible. I used mvn urls in > startup.properties and for the framework but you can use relative paths. > So if you have the startup bundles directly below system you can just refer > to them by file name in the startup.properties. > I also used an interface ArtifactResolver that allows to easily replace > this behaviour. > - Guillaume and you gave the feedback to not introduce new dependencies > and I did not > > So functionally I mainly simplified and restructured the Main code. It > went down from about 950 lines of code to about 400. I think the code is > much more readable and maintainable now. > > There is one nice new feature that is possible now. You can specify the > path to your local maven repo in bundle.locations. In this case karaf can > startup completely without a system directory and directly uses the > local repo. I think this is really nice for developing. As you do not have > to do the assembly step when changing the source of modules in > startup.properties. > > So again sorry for committing too early but I worked really hard on this > the weekend. In the end I had a really nice solution that at this point I > think fitted into all the feedback. > > Christian > > Am 07.05.2012 00:46, schrieb Achim Nierbeck: > > 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 >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -- > > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
