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. Dan > On Dec 9, 2014, at 10:23 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > > On Tue, Dec 9, 2014 at 9:29 AM, Christian Schneider > <ch...@die-schneider.net> 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: http://www.redhat.com >>> Blog: http://willemjiang.blogspot.com (English) >>> http://jnn.iteye.com (Chinese) >>> Twitter: willemjiang >>> Weibo: 姜宁willem >>> >> >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> http://www.talend.com >> > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > Email: cib...@redhat.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > hawtio: http://hawt.io/ > fabric8: http://fabric8.io/ -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
