camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: [discuss] Future of the camel-jetty producer side
Date Tue, 09 Dec 2014 10:18:21 GMT

Jetty 8 (and 7) are already end of life so we’re trying to figure out the “best” way
to get Jetty 9 support so we can get a camel-jetty component that can use a supported version
of Jetty.   So for Camel 2.15, the question, to me, is how to support both 8 and 9 (assuming
we need to support 8 which I think is a good assumption). 

We could have separate “camel-jetty” and “camel-jetty8” components, but there would
be a huge amount of code duplication which is always a concern.   Another option is a camel-jetty-common
with then the two subcomponents depending on that.   That would reduce the duplication, but
would obviously then add another jar/bundle.   Not sure if that is a big deal.   We could
shade that into the two others.  Test class duplication would still be a problem.


> On Dec 9, 2014, at 10:23 AM, Claus Ibsen <> wrote:
> On Tue, Dec 9, 2014 at 9:29 AM, Christian Schneider
> <> wrote:
>> Probably having two versions of camel-jetty is the only viable way then.
>> I am a bit concerned about the code duplication though. The component it
>> self is already quite big and the tests are even bigger. Should we try to
>> move the common things into a separate jar?
> Isn't the irony that OSGi is suppsely to support different versions of
> the same library? But here is a case where it dont, and you need to
> hack camel-jetty :(
>> I think one deciding factor here is how long we plan to support the jetty7
>> and jetty8 camel-jetty. If it is only for a year or so then the duplication
>> might be acceptable as we can remove the old module after this point.
>> If we plan to support it for longer then it is a bigger issue.
> Jetty 7 is no longer supported. The parent/pom uses jetty 8, and there
> is a jetty 9 as well. But any code hacks to support jetty 7 can be
> removed.
> We could support jetty 8 for Camel 2.15. And then drop it for the next
> release, eg 2.16 or what's its version is, requires Jetty9 onwards.
> Then that gives amble time to migrate, and we don't need to have
> camel-jetty9 and other components.
>> Btw. I saw that there are some rest specific classes in camel-jetty and also
>> in camel-http. Does this make sense? Shouldn't rest be a separate layer?
>> I also wonder if we at least could move that part into camel-http completely
>> to make camel-jetty smaller before we split it up.
>> Christian
>> On 09.12.2014 04:10, Willem Jiang wrote:
>>> It’s hard to support two major release version.
>>> How about fork another version of camel-jetty (camel-jetty8) which
>>> supports Jetty7 and Jetty8 and move camel-jetty to support Jetty9 instead.
>>> --
>>> Willem Jiang
>>> Red Hat, Inc.
>>> Web:
>>> Blog: (English)
>>> (Chinese)
>>> Twitter: willemjiang
>>> Weibo: 姜宁willem
>> --
>> Christian Schneider
>> Open Source Architect
> -- 
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email:
> Twitter: davsclaus
> Blog:
> Author of Camel in Action:
> hawtio:
> fabric8:

Daniel Kulp -
Talend Community Coder -

View raw message