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 >
