I agree with Dan that a common module and one module for jetty8 and one
for jetty9 is probably the best route to go. Like Willem mentioned we
can even try to create a http common module if possible. I would start
with a jetty based common module first as it is probably the easier step.
I am not yet sure how to do the sepearation between the common and the
jetty version dependent part. To get a better feeling for it I started
to simply switch the client part to jetty 9 in the current module. So I
can see how the new jetty 9 based module wouldd look like. I plan to
have this fully working till end of the week and will commit it in a
temporary branch for you guys to review.
As a next step we should then define the separation between the modules.
The last step would then be to implement the three modules.
For the karaf feature I plan to use the new conditional descriptors to
install the correct module depending on the karaf runtime. So for karaf
2.4 and 3 it should install the jetty8 one and for karaf 4 it should
install the jetty 9 one.
Both of the modules would be installed with the same feature camel-jetty
and the same prefix jetty: . So this should minimize the impact on
users. This approach should also allow us to work with an upcoming jetty 10.
Do we all agree that on camel master we only need to support jetty 8 and
9 and can safely remove jetty 7 support as Dan has already done?
Christian
On 09.12.2014 11:18, Daniel Kulp wrote:
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
