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 <chetan.mehro...@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 > <marcel.offerm...@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...@gmail.com <paul.bakker...@gmail.com> on behalf of Paul >> Bakker <paul.bak...@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 <fmesc...@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 <tri...@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 >>> >>>
