felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Walker <r...@ascert.com>
Subject Re: Upgrading to Jetty 9
Date Wed, 30 Jul 2014 11:55:35 GMT
We just started a fairly significant chunk of work which would give us 
time to try-out an early/new version of the HTTP Service around Jetty 9. 
So I'd be happy to see an approach that lets us add one to the 
repository, especially if the previous version is there for those who 
need it (and us of course if we find the change too big!)

-- Rob

On 29/07/2014 07:19, Chetan Mehrotra wrote:
> Couple of points wrt Jetty 9 upgrade changes
> - Jetty9 API Changes - Jetty 9 API has changed significantly from 8.x
> hence it would not be possible to create two jars from same project
> - Java 7 requirement - Jetty 9 requires Java 7 for compilation
> Given that changing the symbolic name would cause extra work for users
> when upgrading the HTTP bundle it would be helpful to retain the
> bundle symbolic name. Based on suggestions above I think we can do
> following
> - Branch the current code in jetty module [1] at same level say
> http://svn.apache.org/repos/asf/felix/trunk/http/jetty9. So kind of
> branching but instead of branching to felix/branches we branch
> locally. Otherwise we can also create a branch at [2].
> - Retain the Bundle-SymbolicName but bump the major version to 3.0.x
> - Future releases from current jetty module would stick to 2.x series
> while from Jetty9 would be 3.x series
> - Changes other than those in jetty and itest module can be done in
> compatible way. So those module should be able to work with both
> Jetty8 and Jetty9
> If we have an agreement there I can rework the patch in FELIX-4550
> Chetan Mehrotra
> [1] http://svn.apache.org/repos/asf/felix/trunk/http/jetty/
> [2] http://svn.apache.org/repos/asf/felix/branches/http/jetty
> On Mon, Jul 28, 2014 at 4:30 PM, Marcel Offermans
> <marcel.offermans@luminis.eu> wrote:
>> I agree with the general sentiment that we need to keep moving forward, supporting
the latest version of Jetty.
>> Personally, I'm not sure if an open source project should keep maintaining releases
that run on Java versions that are no longer supported themselves, but this is a broader discussion
and I guess if there are enough people here that care, then we have a good argument to do
>> That said, if we keep two branches, I would like to suggest that we create bundles
with *different* symbolic names, instead of trying to maintain both forks within the same
bundle version range. Since the Jetty 9 effort is new, I suggest we choose a new symbolic
name for it and keep the existing one for the "Java 6 compatible fork".
>> Greetings, Marcel
>> ________________________________________
>> From: paul.bakker.nl@gmail.com <paul.bakker.nl@gmail.com> on behalf of Paul
Bakker <paul.bakker@luminis.eu>
>> Sent: Monday, July 28, 2014 9:16 AM
>> To: dev@felix.apache.org
>> Subject: Re: Upgrading to Jetty 9
>> A major version bump is justified when the bundle doesn't work in
>> environments that previously did work. Note that we're talking about the
>> bundle version, not about package versions. Even the last release (2.3.0)
>> should have been a major bump; it now requires extra bundles to be
>> installed containing APIs, so existing configurations did not longer work.
>> The version number should warn users if the update is a simple drop-in
>> replacement or that other changes might be required.
>> I would be in favour of branching. The Java 6 supported version only gets
>> maintenance updates, while new development continues on Jetty 9. This way
>> developers on Java 6 are not forced to upgrade, but new development is not
>> complicated or limited by the fact that an older version still should be
>> supported.
>> Cheers,
>> Paul
>> On Mon, Jul 28, 2014 at 8:35 AM, Felix Meschberger <fmeschbe@adobe.com>
>> wrote:
>>> Hi
>>> The question really is whether the _internal_ upgrade of the Jetty bundle
>>> to Jetty 9 really is a major change for the Http Service functionality ?
>>> Backwards compatibility is not expected to be hampered. The only
>>> difference, apart from the new features offered potentially by Jetty 9,
>>> such as javax.websockets API support, is that the bundle now requires Java
>>> 7. And I am not really sure, whether an updated requirement really warrants
>>> going to the next major version.
>>> I know dropping Java 6 support is a problem in some cases, but hey, the
>>> world keeps on spinning :-)
>>> If possible, I'd rather create two artifacts from the same project, if at
>>> all possible: One embedding Jetty 8 (supporting Java 6) and one embedding
>>> Jetty 9 (requiring Java 7).
>>> WDYT ?
>>> Regards
>>> Felix
>>> Am 25.07.2014 um 19:29 schrieb Tobias Bocanegra <tripod@apache.org>:
>>>> Hi,
>>>> there is an issue that deals with upgrading jetty to 9.x [0]. As it
>>>> requires java 7, it is not a trivial update. basically the question
>>>> is:
>>>> - create 2 bundles: org.apache.felix.http.[jetty8|jetty9]
>>>> - or update the maven artifact version to 3.0.0 (from 2.4.x)
>>>> I would tend to the later....
>>>> regards, toby
>>>> [0] https://issues.apache.org/jira/browse/FELIX-4550


Ascert - Taking systems to the edge
SA +27 21 300 2028
UK +44 20 7488 3470 ext 5119

View raw message