Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 365186 - javax.xml has extra (original) jar in CVS
Summary: javax.xml has extra (original) jar in CVS
Status: RESOLVED FIXED
Alias: None
Product: Orbit
Classification: Tools
Component: bundles (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 minor (vote)
Target Milestone: ---   Edit
Assignee: David Williams CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-30 08:20 EST by David Williams CLA
Modified: 2012-01-20 15:07 EST (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Williams CLA 2011-11-30 08:20:13 EST 
javax.xml has the original third party jar checked into cvs, as well as the exploded .class files from that jar. We do not need both. The jar is not part of the assembled bundle as distributed ... so, does not hurt much ... but is confusing and unnecessary to have it in cvs.
Comment 1 David Williams CLA 2011-11-30 08:23:56 EST 
To be extra clear, there are cases there there is a "jar" in cvs but on purpose. One example is javax.xml.soap. It uses the old fashioned "nested jar" concept (due to original needs of WTP Project) and keeps the saaj.jar in the lib directory. You can tell this is on purpose (and required), though, since the manifest.mf file has 
Bundle-ClassPath: lib/saaj.jar
Comment 2 David Williams CLA 2012-01-20 15:07:56 EST 
I have fixed this by removing the jar in javax.xml v1_3_4 branch. 

I did not (and do not plan to) retag the bundle, for build, since it was not being included anyway and would not effect delivered bundle. This might still be confusing if someone uses team project set, or something, to load the tagged version, but should be less confusing now ... and be correct if/when it ever needs some other change that requires tagging.