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 > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
