Hi On Thu, Mar 31, 2016 at 5:06 PM, Christian Schneider <ch...@die-schneider.net> wrote: > I recently worked on some projects that also need OSGi settings and found an > interesting thing. > It seems the easiest way to get the exports, imports and other OSGi settings > right is not to use central defaults and instead do all settings per project > while relying on defaults as much as possible. >
Christian is the wording correct? I read this a bit like "do not use central defaults" and then "rely on default as much as possible" are they not the opposite? Do you mean do not use central defaults. And if you must then as little as possible? > I use these settings in the parent: > https://github.com/apache/aries-rsa/blob/master/parent/pom.xml#L199-L223 > > So basically what I do is to only activate the bundle plugin in the parent > and set it to not auto export packages. For bnd-maven-plugin this should not > be necessary as it is the default. > I then delegate the OSGi settings to a bnd.bnd file. This is largely equal > to the pom config but a little less verbose. > > An example can be found at: > https://github.com/apache/aries-rsa/tree/master/rsa > https://github.com/apache/aries-rsa/blob/master/rsa/bnd.bnd > > As you see the pom of each project contains no OSGi informations at all and > the bnd.bnd files are very small. > So I would recommend this approach for camel too. > Ah so instead of having osgi stuff mixed around in parent central pom files, and then with some overlays in current pom.xml, you are solely using a bnd.bnd file per module. So that would mean we would need to do a bnd.bnd file per Camel module that is an OSGi bundle? And how much do you need to configure those bnd.bnd files? Today we get the import|export generated. > Christian > > > On 24.03.2016 16:18, Claus Ibsen wrote: >> >> On Thu, Mar 24, 2016 at 4:10 PM, Quinn Stevenson >> <qu...@pronoia-solutions.com> wrote: >>> >>> I’d be happy to take a shot at the conversion. Is there an appropriate >>> JIRA created already? Or should I continue what you started on the >>> osgi-trouble branch? >>> >> I suggest to start a new branch. The osgi-trouble branch includes >> another upgrade as well that surfaced a bug in the old felix >> bundle-plugin. If we get the osgi fixed then we can cherry-pick the >> caffiene upgrade that are in this branch also. >> >> The new branch could try to aim at >> >> - try to use the bnd plugin >> - if that fails try to upgrade to newer felix plugin >> - upgrade to newer osgi (is that version 5.0 ?) >> - there is some default osgi imports in the parent pom.xml that likely >> need upgrades (i think its in the parent pom) >> >> And a related project is to upgrade the osgi tests in the tests >> directory to use karaf 4.x by default. >> >> >> >> >>>> On Mar 24, 2016, at 8:37 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: >>>> >>>> Hi >>>> >>>> Thanks for sharing the details about the bnd maven plugin. Sounds >>>> promising if its more active maintained and is better. >>>> >>>> Anyone is surely welcome to give it a go on the Camel master branch. >>>> The build system is a bit complicated as there is some default stuff >>>> in parent pom.xml and some ant magic to "massage" maven vs osgi >>>> versions when using SNAPSHOTs and whatnot. Its all part of some old >>>> stuff we needed many years ago when OSGi was new and more buggy. >>>> >>>> I am not so sure we need all that anymore, it would be lovely to make >>>> the build system simpler and easier. >>>> >>>> Sadly I have not seen any tools that can compare a set of JARs against >>>> other JARs to see if their MANIFEST.MF is "the same". Its a bit scary >>>> if the new plugin generates "wrong" imports/exports and the only way >>>> to be sure it works is to run it all in a real osgi container and try >>>> all the components for real. Not only just see if the component can be >>>> installed. >>>> >>>> But then this is what the community is for - to help test - especially >>>> for the people who are using OSGi. >>>> People who are not, you are missing out all the fun ;) ..... or maybe >>>> not. >>>> >>>> A fallback plan is to keep using the old 2.3.7 plugin and then maybe >>>> "hand craft" the camel-core pom.xml instead of generating it to >>>> workaround its issue with Java 1.8 and the caffeine cache. But then we >>>> are stuck on this old dead horse still. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Mar 24, 2016 at 2:47 PM, Quinn Stevenson >>>> <qu...@pronoia-solutions.com> wrote: >>>>> >>>>> Antonin/Claus - >>>>> >>>>> I’ve used the bnd-maven-plugin, and it dramatically reduced the amount >>>>> of configuration I had to do for my bundles. I hit a bug in >>>>> maven-bundle-plugin (https://issues.apache.org/jira/browse/FELIX-5179) and >>>>> moving to the bnd-maven-plugin allowed me to what I needed to do. I even >>>>> provided a patch for the maven-bundle-plugin, but it has yet to be >>>>> applied. >>>>> >>>>> I haven’t explored the intricacies of the Camel build as far as bundle >>>>> manifests are concerned, but I think it would be worthwhile to try the >>>>> bnd-maven-plugin. >>>>> >>>>> >>>>>> On Mar 24, 2016, at 2:28 AM, Antonin Stefanutti >>>>>> <anto...@stefanutti.fr> wrote: >>>>>> >>>>>> Hi Claus, >>>>>> >>>>>> Just in case for info, there is apparently a new BND Maven plugin [1] >>>>>> that is supposed to alleviate some of the issues encountered with >>>>>> maven-bundle-plugin. >>>>>> >>>>>> I haven’t tried it (nor am knowledgeable in the area) but that may be >>>>>> good to know at some point for that piece of work. >>>>>> >>>>>> [1]: >>>>>> http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html >>>>>> >>>>>> Antonin >>>>>> >>>>>>> On 24 Mar 2016, at 07:44, Claus Ibsen <claus.ib...@gmail.com> wrote: >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>> m) >>>>>>> Upgrade OSGi >>>>>>> >>>>>>> We are using osgi 4.3.1 version which whatever OSGi version that is. >>>>>>> But there is a OSGi 5.0 that newer Karaf containers uses. >>>>>>> >>>>>>> But the big pain is upgrading maven-bundle-plugin. We are currently >>>>>>> using an old 2.3.7. But the newer versions have their new sets of >>>>>>> problems / fixes. >>>>>>> >>>>>>> i have struggled with newer versions generating missing details in >>>>>>> the >>>>>>> manifest.mf files. For example camel-core did not export all its >>>>>>> packages etc. A bit scary. But we do have a fair bit of maven >>>>>>> properties and other osgi "magic" to make the build process build >>>>>>> OSGi >>>>>>> modules across all the 250 or so artifacts. >>>>>>> >>>>>>> I pushed to a branch called osgi-trouble where you can see some of >>>>>>> this problems >>>>>>> https://github.com/apache/camel/commits/osgi-trouble >>>>>>> >>>>>>> Using the latest 3.0.1 bundle plugin fails to build camel-core. It >>>>>>> complains something about the osgi activator. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 23, 2016 at 11:07 AM, Claus Ibsen <claus.ib...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> So Camel 2.17 was the last release supporting Java 1.7. >>>>>>>> The next Camel 2.18 is requiring Java 1.8. >>>>>>>> >>>>>>>> Here is some thoughts of mine about this release up for discussion. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> a) >>>>>>>> I see the overall goal of Camel 2.18 as a stepping stone towards >>>>>>>> Java >>>>>>>> 1.8 and Camel 3.0. >>>>>>>> >>>>>>>> By that I mean the release should be a way of moving our existing >>>>>>>> users from Java 1.7 and the current Camel APIs and the likes >>>>>>>> gradually >>>>>>>> towards Java 1.8 and eventually Camel 3.0. >>>>>>>> >>>>>>>> In other words we should not get carried away to change/break APIs >>>>>>>> and >>>>>>>> whatnot just because Java 1.8 lambdas and functions. >>>>>>>> >>>>>>>> There are too many current users that rely on the current Camel API >>>>>>>> and we cannot go around change processor / expression / predicate / >>>>>>>> aggregation strategy and other interfaces to be java 8 functional if >>>>>>>> that means current code cannot compile. And certainly not adding >>>>>>>> Optional<X> as return types all over. >>>>>>>> >>>>>>>> The following releases (Camel 2.19 or 3.0) can pick up that torch >>>>>>>> and >>>>>>>> be more Java 1.8 aggressive. For example Camel 3.0 can expect API >>>>>>>> changes that are Java 8 lambda / functional based. And as well >>>>>>>> changes >>>>>>>> in the DSL to go with that. >>>>>>>> >>>>>>>> There are some minor code changes needed to make the source compile >>>>>>>> as >>>>>>>> source 1.8 to go in this Camel 2.18 let alone. >>>>>>>> >>>>>>>> >>>>>>>> b) >>>>>>>> Drop components that do not support and run on Java 1.8 >>>>>>>> And potentially remove some deprecated components >>>>>>>> >>>>>>>> >>>>>>>> c) >>>>>>>> Drop karaf 2.x. >>>>>>>> And move to karaf 4.x for all our testing. >>>>>>>> >>>>>>>> >>>>>>>> d) >>>>>>>> Drop Jetty 8.x. >>>>>>>> >>>>>>>> This also requires to upgrade at least two components that currently >>>>>>>> rely on Jetty 8 to use Jetty 9. >>>>>>>> >>>>>>>> >>>>>>>> e) >>>>>>>> Upgrade to latest Jetty 9. >>>>>>>> Jetty 9.3 (or is it 9.4) requires Java 1.8 >>>>>>>> >>>>>>>> >>>>>>>> f) >>>>>>>> Drop support for older versions of Spring. We have a number of >>>>>>>> camel-test-spring3 etc modules that can be dropped. And maybe even >>>>>>>> spring 4.0. as its also EOL. >>>>>>>> >>>>>>>> >>>>>>>> g) >>>>>>>> Potentially move spring-dm out of camel-spring into a >>>>>>>> camel-spring-dm >>>>>>>> module. So camel-spring can use latest version of Spring safely. >>>>>>>> This >>>>>>>> also makes it easier to deprecated spring-dm and remove it >>>>>>>> eventually. >>>>>>>> The Karaf team is working on a sping -> blueprint layer so you can >>>>>>>> use >>>>>>>> spring xml files but Karaf will "convert" that under the hood to >>>>>>>> blueprint and run it as blueprint. When that is ready we no longer >>>>>>>> need spring-dm. >>>>>>>> >>>>>>>> >>>>>>>> h) >>>>>>>> Continue adding components docs in the source, eg src/main/doc >>>>>>>> files. >>>>>>>> So we eventually have as many/all of them. This is an ongoing >>>>>>>> effort, >>>>>>>> as we need to do this for the EIPs and the other parts of the docs. >>>>>>>> >>>>>>>> However I see this as a great step for a new documentation and >>>>>>>> website, that IMHO is a big goal for Camel 3.0. To make the project >>>>>>>> website fresh and modern. And make the documentation easier for end >>>>>>>> users to use and view. >>>>>>>> >>>>>>>> >>>>>>>> i) >>>>>>>> Add camel-hysterix component and integrate camel's circuit breaker >>>>>>>> into turbine/hysterix so you can see metrics from camel in the >>>>>>>> dashboard. Eg to integrate with the popular Netflix OSS stack. >>>>>>>> >>>>>>>> >>>>>>>> j) >>>>>>>> Split camel-cxf into modules so we can separate WS and RS and also >>>>>>>> spring vs blueprint. Today its big ball of dependencies that is a >>>>>>>> bit >>>>>>>> hard to slice and dice. Specially for MSA style with REST and you >>>>>>>> dont >>>>>>>> want to add in a bunch of extra not needed JARs. >>>>>>>> >>>>>>>> >>>>>>>> k) >>>>>>>> Continue as usual by adding new components, data formats, fix bugs, >>>>>>>> and so on. >>>>>>>> >>>>>>>> >>>>>>>> l) >>>>>>>> Timeline. This release do not need to have 6-8 months timeframe. We >>>>>>>> could try to get this "stepping stone" release done sooner, so it >>>>>>>> can >>>>>>>> be released during/shortly after summer. >>>>>>>> >>>>>>>> There is plenty of "first work" that we must do with the java 8 >>>>>>>> upgrade and dropping older techs etc, that we have our hands full >>>>>>>> for >>>>>>>> a while. >>>>>>>> >>>>>>>> Doing a release with these changes allows our end users to migrate >>>>>>>> along in a easy way, than a big bang - breaking apis - release would >>>>>>>> do. And the latter would be more appropriate to be released as Camel >>>>>>>> 3.0. >>>>>>>> >>>>>>>> Then towards the end of this year, we can see where we are and plan >>>>>>>> for a Camel 3.0 with a new website and documentation that such a >>>>>>>> release deserve. For example if we release Camel 3.0 in start of >>>>>>>> 2017 >>>>>>>> then its also Camel's 10 year birthday year. >>>>>>>> >>>>>>>> And doing such a release with a rewamped website with fresh looking >>>>>>>> documentation and content, is what helps the project a lot. >>>>>>>> >>>>>>>> The current website looks the same as it did when it was created: >>>>>>>> >>>>>>>> https://web.archive.org/web/20070701184530/http://activemq.apache.org/camel/ >>>>>>>> >>>>>>>> PS: We surely also need a better "what is Camel" story on the front >>>>>>>> page. Its still that very first one with all the tech jumble that >>>>>>>> was >>>>>>>> initially created. >>>>>>>> >>>>>>>> PPS: I would also love to see a new Camel logo. The current one is a >>>>>>>> bit dull and boring. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Claus Ibsen >>>>>>>> ----------------- >>>>>>>> http://davsclaus.com @davsclaus >>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Claus Ibsen >>>>>>> ----------------- >>>>>>> http://davsclaus.com @davsclaus >>>>>>> Camel in Action 2: https://www.manning.com/ibsen2 >>>> >>>> >>>> >>>> -- >>>> Claus Ibsen >>>> ----------------- >>>> http://davsclaus.com @davsclaus >>>> Camel in Action 2: https://www.manning.com/ibsen2 >> >> >> > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
