One clarification on the bnd-maven-plugin configuration - it will inherit configuration from parent bnd.bnd files, so we can have the common configuration we want in the top-level directory, and only override it when needed.
Also - there are some “information only” headers in put in the MANIFEST.MF now (like Import-Service and Export-Service) - do we need those? As Christian said, the tools do a very good job of calculating imported packages. Depending on what we want exported, the Export-Package header may be configured globally as well. > On Apr 1, 2016, at 1:17 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > > Hi > > On Thu, Mar 31, 2016 at 5:06 PM, Christian Schneider > <ch...@die-schneider.net <mailto: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 <http://davsclaus.com/> @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > <https://www.manning.com/ibsen2>
