Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 328900

Summary: Consider making feature qualifier suffixes longer
Product: [WebTools] WTP Releng Reporter: David Williams <david_williams>
Component: relengAssignee: David Williams <david_williams>
Status: RESOLVED FIXED QA Contact: David Williams <david_williams>
Severity: normal    
Priority: P3 CC: pquiring
Version: unspecified   
Target Milestone: 3.10.0   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description David Williams CLA 2010-10-27 21:43:32 EDT 
Due to relatively frequent 'corrupt feature versions', we may want to consider making the suffixes longer, thus reducing the probability of losing significant digits. 

The main problem is a fundamental limitation/difficulty in computing incrementing hashes, see bug 208143. 

Now that we explicitly check, week to week, (see bug 325181) it appears these corrupt features occur fairly often. Such as see bug 328788 and bug 327176. 

While flattening features will help (see bug 297398) another thing that might help is to increase the maximum that's used for truncating feature versions suffixes. I think the default is 28, some teams use 

generatedVersionLength=45
Comment 1 David Williams CLA 2010-10-27 22:44:15 EDT 
One downside of making feature suffixes longer is that "directory names" could end up longer, since they they are part of the feature directory name, and on some OSs, there are limits to how long names (and paths) can be. 

I've done some "statistics" to see if we can increase our feature qualifiers length. I started by seeing what the current longest feature directory name is in Helios SR1 ... the idea being that if the current longest one works ok for users/adopters, then we could increase at least up to that without worry. 

The longest feature directory name in Helios SR1 weighs in at 104 characters, the honor going to 

org.eclipse.datatools.connectivity.oda.designer.core.feature.source_1.8.1.v20100618-7B7C79CcNBGKBgIZCSNS

Seeing that that was a rare one (that is, may be not installed by that many people) I figured I look at the "distribution" of directory name lengths (for features). The "top" of the histogram was as follows: 

 directory    count
   name
  length

	80	10
	81	10
	82	6
	83	9
	84	4
	85	5
	86	9
	87	5
	88	5
	89	3
	90	5
	91	1
	92	2
	93	4
	94	3
	95	1
	96	1
	97	2
	101	1
	104	1

I interpret this to mean anything under 90 or 95 or so would be safe. 

Unfortunately, our longest one in WTP is (already) 87 characters long ... taht as for org.eclipse.jst.jsf.apache.trinidad.tagsupport.feature ... so not sure we can grow too much. 

It is complicated, though, since the qualifier only increases, if needed, so this tagsupport one probably would not grow longer, whereas others, where we really need it, are already shorter, and could grow longer in qualifier. For example, 

org.eclipse.jst.enterprise_ui.feature_v201008190400-7b7GHf2FSK2WBLQ2D-mrubYEOrRh 

is 80 characters long and its qualifier is being truncated at 28 characters, 
so +10 or so probably wouldn't hurt and may help.

 

   

is 87
Comment 2 David Williams CLA 2010-10-27 23:08:20 EDT 
Judging from SR1, we have 9 features that reach the default of 28 character suffixes: 

   org.eclipse.jst.enterprise_ui.feature
   org.eclipse.jst.web_core.feature
   org.eclipse.jst.web_ui.feature
   org.eclipse.wst.common_ui.feature
   org.eclipse.wst.web_core.feature
   org.eclipse.wst.web_ui.feature
   org.eclipse.wst.ws_core.feature
   org.eclipse.wst.ws_ui.feature
   org.eclipse.wst.xml_ui.feature

That matches our experience (so far) in finding ones that "violate" the uniqueness tests.
Comment 3 David Williams CLA 2011-04-19 11:48:40 EDT 
Fixed. Added set featureSuffix property to 38 for our builds. See bug 342908 for some "fall out" this caused.