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
