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?
> 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
