Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 332354 - javax.servlet exports should have 3 digits in their version number
Summary: javax.servlet exports should have 3 digits in their version number
Status: RESOLVED FIXED
Alias: None
Product: Orbit
Classification: Tools
Component: bundles (show other bugs)
Version: unspecified   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Hugues Malphettes CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-11 01:53 EST by Antoine Toulmé CLA
Modified: 2011-03-04 02:23 EST (History)
3 users (show)

See Also:


Attachments
Patch for export with 3 digits (790 bytes, text/plain)
2010-12-11 01:53 EST, Antoine Toulmé CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Antoine Toulmé CLA 2010-12-11 01:53:29 EST
Created attachment 185016 [details]
Patch for export with 3 digits 

The patch attached changes the exports of javax.servlet to have 3 digits. 3 digits are the best practice enforced by OSGi, and some build systems don't consider 2.5 equal to 2.5.0.
Comment 1 David Williams CLA 2010-12-11 19:16:47 EST

> .. 3 digits are the best practice enforced by OSGi, 

Interesting, I've not heard that before. Do you have a link to a reference that says that? I would have thought that to OSGi runtime, "2.5" is fully equivalent to "2.5.0"? 


> and some build systems don't consider 2.5 equal to 2.5.0.

Just to play devil's advocate ... wouldn't that be a bug in those other build systems? That they do not fully support OSGi versioning semantics? What are those "other build systems"? We normally create and provide bundles to run ... it is kind of a slippery slope to customize too much for specific build systems.
Comment 2 Antoine Toulmé CLA 2010-12-11 19:54:17 EST
PDE actually completes the export with a third 0 digit if you don't specify it in the tooling. There is no written doc on this that I could find.

And yes, the real issue is the build system. 

Do you feel this is a customization for a build system ?
Comment 3 David Williams CLA 2010-12-11 20:52:45 EST
> 
> Do you feel this is a customization for a build system ?

I thought that was the reason you wanted it?

I'm not absolutely opposed to having a workaround for a limitation of a build system, but ... a little resistant. Like I said, it is a slippery slope. I could imagine this taking a lot of work, if we had scores of bundles to change in Orbit to accommodate some unnamed build systems.
Comment 4 Hugues Malphettes CLA 2010-12-12 05:31:32 EST
Antoine, let's follow up with the tycho committers then.
If you have a testcase we should file a bug or at least a request for improvement.
Comment 5 Thomas Watson CLA 2010-12-13 08:57:42 EST
(In reply to comment #1)
> 
> > .. 3 digits are the best practice enforced by OSGi, 
> 
> Interesting, I've not heard that before. Do you have a link to a reference that
> says that? I would have thought that to OSGi runtime, "2.5" is fully equivalent
> to "2.5.0"? 
> 

Yes, in OSGi 2.5 is fully equivalent to 2.5.0.

  (new Version("2.5").equals(new Version("2.5.0")) == true

I don't think this best practice is documented anywhere by OSGi and it certainly is not enforced by the runtime.
Comment 6 Antoine Toulmé CLA 2010-12-21 19:40:42 EST
Marking as wont fix. Will follow up on the build system. Thanks for your input!
Comment 7 Hugues Malphettes CLA 2011-03-04 02:16:33 EST
With the recent clean-up of the about.html, javax.servlet_2.5.0 is getting a new version number no matter what.
I would suggest that it is a good time to apply this innocent patch then.
It won't hurt and it will help some crowd of people (err maybe just Antoine and myself...).
Comment 8 Hugues Malphettes CLA 2011-03-04 02:23:11 EST
Fixed with v201103041518