camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com.INVALID>
Subject Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Date Fri, 01 Apr 2016 15:08:31 GMT
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 <quinn@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.ibsen@gmail.com> wrote:
>> 
>> Hi
>> 
>> On Thu, Mar 31, 2016 at 5:06 PM, Christian Schneider
>> <chris@die-schneider.net <mailto:chris@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
>>>> <quinn@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.ibsen@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
>>>>>> <quinn@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
>>>>>>>> <antonin@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.ibsen@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.ibsen@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>


Mime
View raw message