I’d suggest replacing the obsolete Import-Service and Export-Service with actually useful Require-Capability and Provide-Capability headers.
david jencks > On Apr 1, 2016, at 7:01 AM, Quinn Stevenson <qu...@pronoia-solutions.com> > wrote: > > One clarification on the bnd-maven-plugin configuration - it will inherit > configuration from parent bnd.bnd files, so we can have the common > configuration we want in the top-level directory, and only override it when > needed. > > Also - there are some “information only” headers in put in the MANIFEST.MF > now (like Import-Service and Export-Service) - do we need those? > > As Christian said, the tools do a very good job of calculating imported > packages. Depending on what we want exported, the Export-Package header may > be configured globally as well. > >> On Apr 1, 2016, at 1:17 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: >> >> Hi >> >> On Thu, Mar 31, 2016 at 5:06 PM, Christian Schneider >> <ch...@die-schneider.net <mailto:ch...@die-schneider.net>> wrote: >>> I recently worked on some projects that also need OSGi settings and found an >>> interesting thing. >>> It seems the easiest way to get the exports, imports and other OSGi settings >>> right is not to use central defaults and instead do all settings per project >>> while relying on defaults as much as possible. >>> >> >> Christian is the wording correct? I read this a bit like "do not use >> central defaults" and then "rely on default as much as possible" are >> they not the opposite? >> >> Do you mean do not use central defaults. And if you must then as >> little as possible? >> >> >> >> >>> I use these settings in the parent: >>> https://github.com/apache/aries-rsa/blob/master/parent/pom.xml#L199-L223 >>> >>> So basically what I do is to only activate the bundle plugin in the parent >>> and set it to not auto export packages. For bnd-maven-plugin this should not >>> be necessary as it is the default. >>> I then delegate the OSGi settings to a bnd.bnd file. This is largely equal >>> to the pom config but a little less verbose. >>> >>> An example can be found at: >>> https://github.com/apache/aries-rsa/tree/master/rsa >>> https://github.com/apache/aries-rsa/blob/master/rsa/bnd.bnd >>> >>> As you see the pom of each project contains no OSGi informations at all and >>> the bnd.bnd files are very small. >>> So I would recommend this approach for camel too. >>> >> >> Ah so instead of having osgi stuff mixed around in parent central pom >> files, and then with some overlays in current pom.xml, you are solely >> using a bnd.bnd file per module. >> >> So that would mean we would need to do a bnd.bnd file per Camel module >> that is an OSGi bundle? >> And how much do you need to configure those bnd.bnd files? Today we >> get the import|export generated. >> >> >>> Christian >>> >>> >>> On 24.03.2016 16:18, Claus Ibsen wrote: >>>> >>>> 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 >>>> >>>> >>>> >>> >>> >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> http://www.talend.com >>> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> http://davsclaus.com <http://davsclaus.com/> @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 >> <https://www.manning.com/ibsen2>
