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
