Bugzilla – Full Text Bug Listing
| Summary: | javax.servlet package versions for the Servlet 3 specification | ||
|---|---|---|---|
| Product: | [Tools] Orbit | Reporter: | Thomas Watson <tjwatson> |
| Component: | bundles | Assignee: | Thomas Watson <tjwatson> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ccc, daniel_megert, david_williams, glyn.normington, gunnar, hmalphettes, ian.trimble, jesse.mcconnell, john.arthorne, kim.moir, krzysztof.daniel, Mike_Wilson, milesg78, mknauer, mober.at+eclipse, pwebster, raghunathan.srinivasan, ralf.zahn, ruediger.herrmann, thatnitind |
| Version: | unspecified | ||
| Target Milestone: | Juno M4 | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 309529, 365241 | ||
|
Description
Thomas Watson
IMHO technically this all makes sense. However, I'm afraid that exporting the packages version as 2.6 just for the sake of OSGi correctness will cause more confusion than it solves. Frankly, javax.servlet is a 3rd party library. Orbit is just re-packaging it. I would leave it as 3.0 even if that means that a lot bundles in the release train need to have their dependencies updated. (In reply to comment #1) > IMHO technically this all makes sense. However, I'm afraid that exporting the > packages version as 2.6 just for the sake of OSGi correctness will cause more > confusion than it solves. It is unfortunate that we have to build the system on technically incorrect decisions. I guess the industry will never be ready for correctly specifying version semantics between modules. > Frankly, javax.servlet is a 3rd party library. Orbit is just re-packaging it. I > would leave it as 3.0 even if that means that a lot bundles in the release > train need to have their dependencies updated. I don't care at all about the bundles in the release train. At least we will catch these bundles through the testing of the release and they can update their ranges. All I care about are the consumers of the release that have their own bundles. I care that these customers of the release will be impacted by the breaking change. (In reply to comment #2) > All I care about are the consumers of the release that have > their own bundles. I care that these customers of the release will be impacted > by the breaking change. But won't corporate customers/consumers do their own testing and notice broken plug-ins too? From my experience most (of not all?) corporate plug-ins aren't given forward compatibility, i.e. the vendors usually only support their tested combinations *up to* a stated Eclipse release. I also wonder what about consumer that import javax.servlet using [3.0.0,4.0.0) today because they actually want/rely on Servlet 3 features? So either way, someone will break. :( Really unfortunate situation. I remember a similar situation that made we wish I could export packages in multiple versions from my bundle in order to express that my implementation is compatible with 1.x as well as 2.x... That would help here. :) (In reply to comment #3) > So either way, someone will break. :( Really unfortunate situation. I remember > a similar situation that made we wish I could export packages in multiple > versions from my bundle in order to express that my implementation is > compatible with 1.x as well as 2.x... That would help here. :) I didn't really want to go there, but this IS possible ;-) Export-Package: javax.servlet; version=2.6, javax.servlet; version=3.0 Just export the same package multiple times. (In reply to comment #4) > Export-Package: javax.servlet; version=2.6, javax.servlet; version=3.0 > > Just export the same package multiple times. Oh, I didn't know that. Wouldn't that be a possible solution? Are we also sure that there will never be a 2.6 spec maintenance release?
>
> I didn't really want to go there, but this IS possible ;-)
>
> Export-Package: javax.servlet; version=2.6, javax.servlet; version=3.0
>
> Just export the same package multiple times.
If 3.0 version is known to exist the wild (and, presumably, client code written already to "import" [3.0,4.0) or similar), then it seems this is (only) good alternative? Any downside? Is the bundle ID an issue here? What would our advise to clients be? I'd assume to encourage them to (still) stick with import
package [2.x,3.0)?
(In reply to comment #6) > > > > I didn't really want to go there, but this IS possible ;-) > > > > Export-Package: javax.servlet; version=2.6, javax.servlet; version=3.0 > > > > Just export the same package multiple times. > > If 3.0 version is known to exist the wild (and, presumably, client code written > already to "import" [3.0,4.0) or similar), then it seems this is (only) good > alternative? Any downside? Is the bundle ID an issue here? What would our > advise to clients be? I'd assume to encourage them to (still) stick with import > package [2.x,3.0)? The issue is not the bundle ID since the best practice for accessing javax packages from orbit bundles should be to use Import-Package. The issue is the package version which the javax.servlet 3.0 bundle is exporting the javax.servlet packages at. it is exporting them at version 3.0 so if we had a client bundle using import package [2.x, 3.0) then they are busted. From an eclipse perspective jetty 8 has been released and includes the javax.serlvet 3.0 bundle. So changing the package version to anything less that 3.0 could be disruptive to the Jetty 8 community/users. There are not any good alternatives in my mind. Here are the options as I see them: 1) Leave the package versions as they are already (3.0). This means we must have a breaking change in Equinox/Eclipse and have a porting guideline entry advising that clients of javax.servlet can ignore the best practice for ranges and use something like [2.x, 4.0). Of coarse when servlet 4.0 comes out we will be in this same boat again unless we can convince the servlet API bundle providers to use proper package version evolution in the next version of the specification. 2) Go back to glashfish and inform them that the package version is not correct for the servlet 3.0 API bundle. I plan to do this, but I think they would be equally concerned about breaking their current clients as Jetty 8 would. Moving a package version back in sequence is also considered a breaking change. 3) Have the orbit javax.servlet 3 bundle export the packages at version 2.6 and 3.0. A slight alternative is to have a fragment to the javax.servlet 3 bundle that exports the packages at version 2.6. Yes you can do this but it is confusing, the host will export the package once for each version (e.g. 2.6 and 3.0). Perhaps 1) is our only option (I will not use the word "good" to describe it) ;-) We can consider a compatibility fragment that adds the export for the package 2.6 if it is a real problem. Just to play devil's advocate ... I have heard it said "interface packages should be versioned according to the level of their spec (even if implementation packages increase according to bug fixes, etc.)" (to paraphrase) ... so, I can see how it'd be tempting to export according to "spec level" (though, I could not find a reference to that guideline ... nor do I know much about javax.servlet API ... they might have said "these x packages stay the same as 2.5, but these y new ones are added for 3.0 ... or something implying a strong relationship of interfaces to spec level ... but, seems unlikely). But ... thought I'd through that out there as kind of a justification for 3.0 being "ok" :/ (In reply to comment #8) The servlet-api-3.0 does not try to isolate the changes by packages or even objects. (In reply to comment #7) IMO The compatibility fragment or exporting 2 versions of the package seem fine. The jetty devs (Greg) confirm that no servlet-2.6 spec is planned. They are suggesting to eventually use this pattern for the backward compatibility version: Export-Package: javax.servlet; version=2.9.30, javax.servlet; version=3.0.0 Which will later become: Export-Package: javax.servlet; version=2.9.31, javax.servlet; version=3.1.0 (In reply to comment #7) > 1) Leave the package versions as they are already (3.0). This means we must > have a breaking change in Equinox/Eclipse and have a porting guideline entry > advising that clients of javax.servlet can ignore the best practice for ranges > and use something like [2.x, 4.0). Of coarse when servlet 4.0 comes out we > will be in this same boat again unless we can convince the servlet API bundle > providers to use proper package version evolution in the next version of the > specification. This feel like the right answer to me. I actually think we should not be encouraging use of an upper bound at all for third party libraries that don't evolve according to our semantics. In fact I thought this was already the recommendation: http://wiki.eclipse.org/index.php/Version_Numbering#Versioning_plug-ins_that_wrap_external_libraries We have to keep in mind that *our* versioning semantics based strictly on binary API compatibility are not universal. While we can recommend that others adopt that model, in the end I think we have to live with the version numbers chosen by the third party library. Geronimo 3 M1 (http://geronimo.apache.org/apache-geronimo-v30-m1-release.html) also packages a bundle that exports the javax.servlet 3 packages. They use this Export-Package header: Export-Package: javax.servlet; uses:="javax.servlet.annotation,javax.servlet.descriptor" version="2.6", javax.servlet.annotation; uses:="javax.servlet" version="2.6", javax.servlet.descriptor; version="2.6", javax.servlet.http; uses:="javax.servlet"; version="2.6", javax.servlet.resources; version="2.6", javax.servlet; version="3.0", javax.servlet.annotation; version="3.0", javax.servlet.descriptor; version="3.0", javax.servlet.http; version="3.0", javax.servlet.resources; version="3.0" So they appear to take the double version approach. I think we are free to do this in our orbit version if we want to. I also suspect the glassfish folks will want to do this in their version eventually. (In reply to comment #10) > We have to keep in mind that *our* versioning semantics based strictly on > binary API compatibility are not universal. While we can recommend that others > adopt that model, in the end I think we have to live with the version numbers > chosen by the third party library. I agree, but in this case we have a 3rd party source (glassfish) that I think we should go back to and discuss what we *think* is the proper way to version packages. If they agree, then we can make the change locally in our orbit version and then pick up the fixed version from glassfish at some point in the future. Double versioning packages is just wrong. Export-Package: javax.servlet; version="2.6", javax.servlet; version="3.0" This will export the same source for javax.servlet under two versions 2.6 and 3.0. Lets imagine the Servlet 3.1 specification is now released. This would result in the following export: Export-Package: javax.servlet; version="2.7", javax.servlet; version="3.1" Now imagine a bundle that has a dependency on the javax.servlet package from the Servlet 3.1 specification. They would have the following import: Import-Package: javax.servlet; version="2.7" If they put no limit on the range they will happily get wired to either exported packages above. Clearly they only want the one from the second Export-Package. This will not work as long as more versions can get inserted between 2.6 and 3.0. I opened glashfish issue at http://java.net/jira/browse/GLASSFISH-17410 (In reply to comment #12) > Now imagine a bundle that has a dependency on the javax.servlet package from > the Servlet 3.1 specification. They would have the following import: > > Import-Package: javax.servlet; version="2.7" If I build a bundle at some time in the future and I know I'll depend on 3.1 API I would import the package using version 3.1. Importing that using 2.7 sounds confusing to me. I thought the main issue for exporting 2.x versions is with backwards compatibility so that bundles importing using with [2.x,3.0) continue to work with the new Servlet API (as long as it's compatible). Upper version ranges are always a problem since nobody can look into the future. My immediate reaction would be that 3.0 is a correct version, and consumers who did specify a 3.0) upper version range have to update their bundles. Even if on the API side, the 3.0 upgrade only affects implementers and not consumers - is there a guarantee that aside API signatures the API semantics are 100% compatible? Inventing anything that looks odd and quirky isn't worth it just for supporting legacy. That being said I'm wondering if there's any approaches that do not look odd and quirky: - Is it possible in a large install for a 3.0 servlet container and 2.5 servlet container to peacefully coexist? Such that legacy software could continue using the legacy servlet container? - Is it possible to define a "compatibility bundle" which imports 3.0 and re-exports as 2.6 ? (In reply to comment #15) > Upper version ranges are always a problem since nobody can look into the > future. Upper bounds are only an issue if the package versions have no semantics behind them. In my opinion we should strive to have package versions that have semantic meaning. Otherwise I completely agree with you! Upper bounds would be very problematic if versions have no semantic meaning. The Servlet as a Specification moved to 3.0 for marketing purposes. Moving the package versions from 2.5 all the way to 3.0 for marketing purposes makes no semantic sense. This is a familiar conversation. It is similar to the discussions in Eclipse just after Eclipse 3.0 was released. In that release we moved most of the Eclipse bundles up to bundle version 3.0 even though from an API POV they were backwards compatible. Since then we have matured and have correctly decided to place semantic meaning behind our bundle versions. This is the same discussion except it is around package versions. In my opinion, it is unfortunate if we just except incorrect package version semantics without at least trying to influence the producers to do the right thing. > My immediate reaction would be that 3.0 is a correct version, and > consumers who did specify a 3.0) upper version range have to update their > bundles. Even if on the API side, the 3.0 upgrade only affects implementers and > not consumers - is there a guarantee that aside API signatures the API > semantics are 100% compatible? According to the experts involved in the specification, yes. > > Inventing anything that looks odd and quirky isn't worth it just for supporting > legacy. That being said I'm wondering if there's any approaches that do not > look odd and quirky: I doubt it, I think that we must stick with a single version for the packages. Trying to double version the packages is wrong. > > - Is it possible in a large install for a 3.0 servlet container and 2.5 > servlet container to peacefully coexist? Such that legacy software could > continue using the legacy servlet container? Perhaps it is possible, but I do not think it is worth the effort. > > - Is it possible to define a "compatibility bundle" which imports 3.0 > and re-exports as 2.6 ? Sure, but this has all the same downsides as double versioning. I also find it confusing to call this the "compatibility bundle" since it really is the correct semantics to version the packages at version 2.6. So I would call it the "semantically correct bundle". We have two open source communities producing Servlet 3.0 Specification API bundles. Initially Geronimo has decided to double version their packages, in their first milestone. I have spoken with folks involved in the Geronimo community and expect they will discuss dropping the 3.0 and only exporting with version 2.6 because of the issues around double versioning packages. Glassfish decided to go with 3.0 package versions. I have opened a bug against them to discuss this and we can see what they decide. In the end, I would very much like to get these two communities to agree on one version, be that package version 3.0 or 2.6. Then I would recommend we follow the version they decide on. Otherwise, we will not have compatible bundles that can run in all Servlet 3.0 containers. IMHO double versioning of packages is not a good way. Okay, it would solve this single problem for now, but let's think about the future. What if the next releases of the Servlet API are versioned the same way? So a Servlet API V4 is released that is also not breaking the API? We now have Servlet API == OSGi package versions V2.5 == 2.5 V3.0 == 2.6, 3.0 V3.1 == 2.7, 3.1 V4.0 == 2.8, 3.2, 4.0 V5.0 == 2.9, 3.3, 4.1, 5.0 So we have multiple versioning of packages. For me, there are the following solutions: 1. There is a possibility to influence the JSR to follow the versioning rules like OSGi. But what would the marketing say? (I'm not familiar with that.) So there will be version deviations in the future (not only limited to the Servlet API). For me, this is a common question that should get cleared within the OSGi community. This could lead to the following decisions: 2. Use the spec versions 1:1, so use javax.servlet 3.0. This lets clients fall into resolver exceptions, but does not confuse. 3. Use the OSGi versioning rules independently from the specs version. Maybe write a documentation that maps specs versions to OSGi package versions. OSGi bundle implementors need to know about the deviation, but can rely on the versioning rules without any exception. 4. Use the specs version 1:1, but introduce a mechanism to tell the resolver that package version 3.0 does not break the API with 2.5. Package importing bundles should then have another version range statement like [2.5,) to tell the resolver that all versions of 2.5 and later are allowed that do not break with the API. 5. Use the OSGi versioning rules, but introduce a second version number (optional) to refer to the specs version. So we export package Export-Package: javax.servlet; version=2.6;spec=3.0 and could use Tools like PDE to find javax.servlet spec 3.0 and include javax.servlet version 2.6 into the manifest file. (My favorite would be 3. or 5.) (In reply to comment #17) > IMHO double versioning of packages is not a good way. Okay, it would solve this > single problem for now, but let's think about the future. What if the next > releases of the Servlet API are versioned the same way? So a Servlet API V4 is > released that is also not breaking the API? > > We now have > > Servlet API == OSGi package versions > V2.5 == 2.5 > V3.0 == 2.6, 3.0 > V3.1 == 2.7, 3.1 > V4.0 == 2.8, 3.2, 4.0 > V5.0 == 2.9, 3.3, 4.1, 5.0 I agree, multi versioning is a nightmare for future evolution of the package versions. That is not an option IMO. > > So we have multiple versioning of packages. For me, there are the following > solutions: > > 1. There is a possibility to influence the JSR to follow the versioning rules > like OSGi. But what would the marketing say? (I'm not familiar with that.) > > So there will be version deviations in the future (not only limited to the > Servlet API). For me, this is a common question that should get cleared within > the OSGi community. This could lead to the following decisions: > > 2. Use the spec versions 1:1, so use javax.servlet 3.0. This lets clients fall > into resolver exceptions, but does not confuse. > 3. Use the OSGi versioning rules independently from the specs version. Maybe > write a documentation that maps specs versions to OSGi package versions. OSGi > bundle implementors need to know about the deviation, but can rely on the > versioning rules without any exception. > 4. Use the specs version 1:1, but introduce a mechanism to tell the resolver > that package version 3.0 does not break the API with 2.5. Package importing > bundles should then have another version range statement like [2.5,) to tell > the resolver that all versions of 2.5 and later are allowed that do not break > with the API. > 5. Use the OSGi versioning rules, but introduce a second version number > (optional) to refer to the specs version. So we export package > Export-Package: javax.servlet; version=2.6;spec=3.0 > and could use Tools like PDE to find javax.servlet spec 3.0 and include > javax.servlet version 2.6 into the manifest file. > > (My favorite would be 3. or 5.) My preference is 3 followed by 2. I also agree that the OSGi community should get involved in this decision. 4 and 5 involve changing the OSGi specification and or tooling to satisfy a degenerative case where package version semantics was not followed. In that case I would rather just bit the bullet and except that such packages evolve their versions in ways that are not semantically correct. (In reply to comment #18) > > 2. Use the spec versions 1:1, so use javax.servlet 3.0. This lets clients fall > > into resolver exceptions, but does not confuse. > > 3. Use the OSGi versioning rules independently from the specs version. Maybe > > write a documentation that maps specs versions to OSGi package versions. OSGi > > bundle implementors need to know about the deviation, but can rely on the > > versioning rules without any exception. > My preference is 3 followed by 2. If it can't be fixed at the source, I prefer 2. It's what we had to do with ICU4J (3.6, 3.8, 4.0, 4.2 with no changes in binary compatibility). The lesson learned there was you shouldn't use upper bounds on 3rd party libraries, and we (Eclipse) shouldn't add semantic information ourselves if we can't guarantee that the source won't change in the future in such a way as to make it fail unexpectedly. PW (In reply to comment #19) > (In reply to comment #18) > > > 2. Use the spec versions 1:1, so use javax.servlet 3.0. This lets clients fall > > > into resolver exceptions, but does not confuse. > > > 3. Use the OSGi versioning rules independently from the specs version. Maybe > > > write a documentation that maps specs versions to OSGi package versions. OSGi > > > bundle implementors need to know about the deviation, but can rely on the > > > versioning rules without any exception. > > My preference is 3 followed by 2. > > If it can't be fixed at the source, I prefer 2. It's what we had to do with > ICU4J (3.6, 3.8, 4.0, 4.2 with no changes in binary compatibility). The lesson > learned there was you shouldn't use upper bounds on 3rd party libraries, and we > (Eclipse) shouldn't add semantic information ourselves if we can't guarantee > that the source won't change in the future in such a way as to make it fail > unexpectedly. > > PW Of course, if you do not follow the OSGi versioning rules for a package import, you cannot apply best practises for the package import. I prefer 3. because it fits to reality in the best way. We have a technical version that is read by the OSGi resolver and that tells about API changes. And we have a "human" version that tells persons about the changes of a library. If there are big changes in the Servlet API, we increment from 2.x to 3.x. Why does Java itself use version numbers like Java2, Java5, Java6, Java7 but use a compiler level 1.2, 1.3, 1.4, 1.5, 1.6, 1.7 and so on? If we use 3., we do not exclude 5. in the future, because including the "human" version into the OSGi headers would just be an extension that is used by tooling. This extension is optional and even does not have to be introduced by OSGi. We could also include the mapping of the versions into the tooling without changing the OSGi specs. FWIW the OSGi Alliance is going to publish a document on its wiki that provides the recommendation for the package versions for the various JavaEE packages (including javax.servlet). In the initial draft of the document I am told they will recommend Servlet 3 use package versions of 2.6. No where will they recommend multi versions of a single package. I just noticed that Jesse updated the package version to be 2.6 in orbit. http://dev.eclipse.org/viewsvn/viewvc.cgi/org.eclipse.orbit/javax.servlet/META-INF/MANIFEST.MF?view=markup&root=Tools_Project&pathrev=v3_0 Jesse, is this going to be issue for existing users of the javax.servlet bundle? I'm not suggesting we don't do this. Just trying to coordinate how we stage this change to the community. For example, in Eclipse/Equinox projects we are including the javax.servlet 3.0 bundle in M4. We should make sure to get the latest version from orbit with these changes before M4 is done. Thomas, in short...I have no idea, I say we push it and let the chips fall where they may :) *cue maniacal laughter* Also, I have not pushed that change into an orbit build yet as I wanted to check with hugues if the bundle version ought to be 2.6.0.qualifier as well or should it remain 3.0.0.qualifier? (In reply to comment #23) > Thomas, > > in short...I have no idea, I say we push it and let the chips fall where they > may :) *cue maniacal laughter* > > Also, I have not pushed that change into an orbit build yet as I wanted to > check with hugues if the bundle version ought to be 2.6.0.qualifier as well or > should it remain 3.0.0.qualifier? I would keep the bundle version at 3.0.0. In the end the bundle version is not as important. The best practice is that clients use Import-Package and never use Require-Bundle for packages exported from orbit bundles. The M4 milestone is next week for platform, and it would be good if we had the new javax.servlet in there so an ripple effects can be sorted out. My understanding is the change is in orbit, but we need an orbit build to pick it up? As an aside I have a concrete case where the javax.servlet package version is 3.0 causing problems. In Orion we consume jetty from platform, but also use Solr. Solr relies on org.apache.commons.el, which specifies a dependency on javax.serlvet [2.4,3.0). From what I can tell org.apache.commons.el hasn't released a new version since 2003 so I suspect we're stuck with that version forever. Currently I can't use the new Jetty along with my current Solr because of this. Gunnar I suspect this would bite you too. I guess we could have hacked our orbit copy of apache.commons.el to change its dependency range to workaround that. Appears "in Orbit" in CVS, and even tagged with v201111160755 but bundles.map file not updated ... it still has v201111151307 which exports "3.0". Let me know if you need help (as we are due to promote S build on Friday) ... otherwise, I assume maintainers will handle as appropriate. ok, I was waiting to confirm something with hugues on that before I got distracted with other things... I'll try and get it updated in the orbit build tomorrow unless hugues happens to see this tonight and takes care of it. fair warning I have made the commit to orbit and the build should trigger soon with it...will monitor to make sure it succeeds ok, marking this resolved for now... Tom, anything else on this issue? I'll move this to Orbit where the fix was made. (In reply to comment #29) > ok, marking this resolved for now... > > Tom, anything else on this issue? Is there a new jetty version we can use which imports the javax.servlet packages at the lower 2.6 version? (In reply to comment #31) > (In reply to comment #29) > > ok, marking this resolved for now... > > > > Tom, anything else on this issue? > > Is there a new jetty version we can use which imports the javax.servlet > packages at the lower 2.6 version? Tom, Jesse and I were discussing whether we need to do that. At the time I was telling Jesse that we Jetty can keep importing 3.0: - a web-bundle imports [2.5,3.0) - jetty imports 3.0 In practice both jetty and the web-bundle are using the same servlet-bundle with a 2.6 version of the packages. Does this mean that everything is fine or in fact this combination cannot run together? (In reply to comment #32) > (In reply to comment #31) > > (In reply to comment #29) > > > ok, marking this resolved for now... > > > > > > Tom, anything else on this issue? > > > > Is there a new jetty version we can use which imports the javax.servlet > > packages at the lower 2.6 version? > Tom, Jesse and I were discussing whether we need to do that. > At the time I was telling Jesse that we Jetty can keep importing 3.0: > - a web-bundle imports [2.5,3.0) > - jetty imports 3.0 > In practice both jetty and the web-bundle are using the same servlet-bundle > with a 2.6 version of the packages. > Does this mean that everything is fine or in fact this combination cannot run > together? imports 3.0 means import-packages that export 3.0 or greater .... so, that'd results in a "not found" (or, "not resolved") for the new javax.servlet. Sounds like the web-bundle one would be satisfied, if you are talking about "import package" ... if you are talking about "require bundle", that's something else, but suspect you don't use "require bundle". [And, sounds like [2.5,3.0) would not have worked with the old one .... since that means equal to 2.5 and (strictly) less than 3.0.] The new javax.servlet is in Orbit's I build at http://download.eclipse.org/tools/orbit/downloads/drops/I20111201180206/ if that helps you confirm/test anything. That build will be renamed to S build on Friday afternoon for projects to use for Juno M4. HTH (and, hope I'm not misunderstanding your question). (In reply to comment #33) > HTH (and, hope I'm not misunderstanding your question). Thanks David. Sorry my question was not crystal clear. Sorry for this poor habit of mine; I attempted to answer my own question instead asking the question: Tom, why would you be looking for a version of jetty that imports the packages of javax.servlet with [2.6,infinite)? It is not a big deal to change them. But I am really interested to understand the impact. It was my understanding that sticking to [3.0,infinite) was fine for the jetty bundles. For the coming Juno milestone we can only use the latest jars of jetty in maven central. So we won't have to change that for next week. (In reply to comment #34) > It was my understanding that sticking to [3.0,infinite) was fine for the jetty > bundles. If the bundle in Orbit does export the packages as version 2.6 then you need to set the lower bounds to include at least 2.6. Otherwise the bundles won't resolve using the new Orbit bundle. (In reply to comment #35) > (In reply to comment #34) > > It was my understanding that sticking to [3.0,infinite) was fine for the jetty > > bundles. > > If the bundle in Orbit does export the packages as version 2.6 then you need to > set the lower bounds to include at least 2.6. Otherwise the bundles won't > resolve using the new Orbit bundle. OK: I get it now. I somehow totally missed the basics we were debating in this bug. Sorry about that. Looks like we have no choice but to rush a new jetty build somehow. (In reply to comment #36) > Looks like we have no choice but to rush a new jetty build somehow. Let me re-phrase this: we are working on it and will provide a new repo with the updated jetty-bundles for testing for this Friday. We might not have time for this Milestone to make a full build with the usual process where jetty is released in maven-central first and published later at eclipse in a p2repo. (In reply to comment #37) Here is a snapshot build of the jetty bundles where all the javax.servlet imports have been re-factored from 3.0 to 2.6 http://download.eclipse.org/jetty/updates/jetty-bundles-8.x/8.1.0.SNAPSHOT/ I made sure that I could build the jetty-p2 products and install them with p2-director only relying on the new version of javax.servlet that exports 2.6 alone. I am having issues with hudson@eclipse and nexus [1] so I ended up uploading this p2repo directly from my machine. We will look into making a new release build of jetty-8.1.0 with those changes later today and doing the rest of the proper build procedure. [1] http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg06797.html (In reply to comment #38) > (In reply to comment #37) > Here is a snapshot build of the jetty bundles where all the javax.servlet > imports have been re-factored from 3.0 to 2.6 > > http://download.eclipse.org/jetty/updates/jetty-bundles-8.x/8.1.0.SNAPSHOT/ > > I made sure that I could build the jetty-p2 products and install them with > p2-director only relying on the new version of javax.servlet that exports 2.6 > alone. > > I am having issues with hudson@eclipse and nexus [1] so I ended up uploading > this p2repo directly from my machine. > > We will look into making a new release build of jetty-8.1.0 with those changes > later today and doing the rest of the proper build procedure. > > [1] http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg06797.html Thanks for the quick support on this Hugues. I have been testing out the new build of 8.1 and I noticed something that appears to be a breaking change, but I can react in the equinox.http.jetty bundle to make it work. It appears that the type org.eclipse.jetty.http.ssl.SslContextFactory has moved to org.eclipse.jetty.util.ssl.SslContextFactory and so now the return type of org.eclipse.jetty.server.ssl.SslSocketConnector.getSslContextFactory() has changed. I have committed a change to work around this, but it required me to use deprecated methods on SslSocketConnector. See commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=0d6e7a31b65d642cdc3c37eabf07b8776319a31f (In reply to comment #39) > It appears that the type org.eclipse.jetty.http.ssl.SslContextFactory has moved > to org.eclipse.jetty.util.ssl.SslContextFactory and so now the return type of > org.eclipse.jetty.server.ssl.SslSocketConnector.getSslContextFactory() has > changed. > > I have committed a change to work around this, but it required me to use > deprecated methods on SslSocketConnector. See commit: > > http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=0d6e7a31b65d642cdc3c37eabf07b8776319a31f To support websockets in the jetty-client, the SslContextFactory was moved to jetty-util: it can be used both by jetty-client and jetty-server. However just a naive question: would it be OK to use the new package for the SslContextFactory to avoid using the deprecated methods? (In reply to comment #40) > To support websockets in the jetty-client, the SslContextFactory was moved to > jetty-util: it can be used both by jetty-client and jetty-server. > > However just a naive question: would it be OK to use the new package for the > SslContextFactory to avoid using the deprecated methods? It will be OK, we will have to tighten our ranges to make sure we import [8.1, 9.0) of the jetty packages. I opened bug 365590 for this. Reopening this to discuss servlet 3.1 versioning... what will this be....2.7 or 2.6.1? (In reply to comment #42) > Reopening this to discuss servlet 3.1 versioning... > > what will this be....2.7 or 2.6.1? My guess is 2.7 since I would not think a completely new specification for servlet would be released with no API or additional semantic behavior for clients. Can you close this bug and open a new bug for servlet 3.1? closing since I have my answer, no need to open a new one afaict thanks! |