Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 313559 - EMF Build is adding version tolerances to MANIFEST.MF files
Summary: EMF Build is adding version tolerances to MANIFEST.MF files
Status: CLOSED FIXED
Alias: None
Product: EMF
Classification: Modeling
Component: Releng (show other bugs)
Version: 2.6.0   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Kenn Hussey CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 313850 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-05-19 11:45 EDT by Paul Elder CLA
Modified: 2018-01-22 11:36 EST (History)
4 users (show)

See Also:
Kenn.Hussey: pmc_approved?

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 Paul Elder CLA 2010-05-19 11:45:48 EDT 
In CVS, the plug-in org.eclipse.emf.importer specifies no version tolerances on plug-in org.eclipse.core.resources. 

The tight tolerances in the M7 build coupled with some unexpected changes in the qualifier used by org.eclipse.core.resources is breaking builds.

(org.eclpise.core.resources M6 has qualifier v20100310-1650, M7 has v20100427-2200, while RC1 has the alphabetically earlier V20100513-0800. Notice the upper case V.  See bug 313558)

For the record, tolerances expressed in org.eclipse.emf.importer have been:

2.6RC1: 
org.eclipse.core.resources;bundle-version="[3.6.0.V20100513-0800,4.0.0)",

In 2.6M7:
org.eclipse.core.resources;bundle-version="[3.6.0,3.7.0)",

In 2.6M6:
no tolerances (like the source file)

IMHO, the proper place for version tolerances in the source code - the build should not be adjusting tolerances.
Comment 1 Ed Merks CLA 2010-05-21 09:36:19 EDT 
*** Bug 313850 has been marked as a duplicate of this bug. ***
Comment 2 Kenn Hussey CLA 2010-05-21 17:03:46 EDT 
The algorithm for computing version tolerances has been updated so that it is now the same as it has been for the last several years. The RC2 build, which reflects the desired tolerances (as in builds up to M5), has been posted.
Comment 3 David Williams CLA 2010-05-21 22:34:37 EDT 
(In reply to comment #2)
> The algorithm for computing version tolerances has been updated so that it is
> now the same as it has been for the last several years. The RC2 build, which
> reflects the desired tolerances (as in builds up to M5), has been posted.

What is that algorithm, exactly? Does it end up stored in source, in cvs? (I ask, since I'm wondering how someone reproduces your build on their own build system? ... but, I'm not doing that :) just wanted general idea, no details needed). 

thanks,
Comment 4 Kenn Hussey CLA 2010-05-24 09:30:09 EDT 
The lower and upper bounds for dependency version tolerances are generated by Buckminster during the build. In this case, were are (now) using an 'equivalent' lower bound and a 'compatible' upper bound, as specified via the pde.match.rule.retain.lower and pde.match.rule.default build properties. Details can be found in bug 309141.

The versions are generated during the build but do not end up in CVS, as has long been the case for EMF builds. I don't know how someone would reproduce this on their own build system, to be honest, unless they're using Buckminster or a variant of PDE build similar to the "old" Modeling build system...
Comment 5 Ed Merks CLA 2018-01-22 11:36:00 EST 
Closing all fixed releng bugs.