You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Tobias Bocanegra <tr...@apache.org> on 2014/07/25 19:29:44 UTC
Upgrading to Jetty 9
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
Re: Upgrading to Jetty 9
Posted by Carsten Ziegeler <cz...@apache.org>.
2014-07-28 8:35 GMT+02:00 Felix Meschberger <fm...@adobe.com>:
>
> 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).
>
>
Yes, that's my preference as well and afaik that's what we are currently
trying to go with.
Matter of fact is that we have many users with Java 6 out there - and we
definitely don't want to loose them.
Carsten
WDYT ?
>
> Regards
> Felix
>
> Am 25.07.2014 um 19:29 schrieb Tobias Bocanegra <tr...@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
>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Upgrading to Jetty 9
Posted by Rob Walker <ro...@ascert.com>.
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
> <ma...@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 so.
>>
>> 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 <pa...@gmail.com> on behalf of Paul Bakker <pa...@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 <fm...@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 <tr...@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
robw@ascert.com
SA +27 21 300 2028
UK +44 20 7488 3470 ext 5119
www.ascert.com
Re: Upgrading to Jetty 9
Posted by Tobias Bocanegra <tr...@apache.org>.
Hi,
I don't have much voting power here....but I'm agree with chetan.
On Mon, Jul 28, 2014 at 10:19 PM, Chetan Mehrotra
<ch...@gmail.com> 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].
so: cp -R trunk/http/jetty trunk/http/jetty9;
+1 for that
> - Retain the Bundle-SymbolicName but bump the major version to 3.0.x
+1
> - Future releases from current jetty module would stick to 2.x series
> while from Jetty9 would be 3.x series
+1
> - 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
+1
> If we have an agreement there I can rework the patch in FELIX-4550
thanks for driving this forward.
regards, toby
>
> 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
> <ma...@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 so.
>>
>> 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 <pa...@gmail.com> on behalf of Paul Bakker <pa...@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 <fm...@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 <tr...@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
>>>
>>>
Re: Upgrading to Jetty 9
Posted by Chetan Mehrotra <ch...@gmail.com>.
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
<ma...@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 so.
>
> 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 <pa...@gmail.com> on behalf of Paul Bakker <pa...@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 <fm...@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 <tr...@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
>>
>>
RE: Upgrading to Jetty 9
Posted by Marcel Offermans <ma...@luminis.eu>.
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 so.
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 <pa...@gmail.com> on behalf of Paul Bakker <pa...@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 <fm...@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 <tr...@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
>
>
Re: Upgrading to Jetty 9
Posted by Paul Bakker <pa...@luminis.eu>.
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 <fm...@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 <tr...@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
>
>
Re: Upgrading to Jetty 9
Posted by Felix Meschberger <fm...@adobe.com>.
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 <tr...@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