Bug 400215 - Clarify documentation/comments on the *,*,* config
Summary: Clarify documentation/comments on the *,*,* config
Status: RESOLVED WONTFIX
Alias: None
Product: PDE
Classification: Eclipse Project
Component: Build (show other bugs)
Version: 4.2.1   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: pde-build-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: Documentation
Depends on:
Blocks:
 
Reported: 2013-02-07 09:00 EST by Nikolas Falco CLA
Modified: 2018-12-03 09:05 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolas Falco CLA 2013-02-07 09:00:02 EST
My headless build is based on eclipse 4.2.1

eclipse.buildScript task doesn't produce build.xml for fragments having os, ws or arch specified in the feature.xml, although "config" property in build.properties is set to config=*,*,*

While debugging I found what I believe is a problem in class org.eclipse.pde.internal.build.site.compatibility.SiteManager.isMatching(String candidateValues, String siteValues). 
As you know, during the build, when the eclipse.buildScript collects all plugins and features to be built, it checks that their architecture matches the architecture of the eclipse platform against which the source code is to be built.

The list of all collected plugins is computed from the involved feature.xml and attributes os, ws or arch are matched against values described by the config property. 

But in my setup the SiteManager.isMatching("x86", "*") always returns false.

It returns true when:
- candidateValues is *
- candidateValues is ""
- candidateValues contains value listed into siteValues

where candidateValues come from the plugin attributes declared in feature.xml

Apparently, this scenario is not supported:
- siteValues is *, which should match anything according to the comments in template build.properties:
# The list of {os, ws, arch} configurations to build.  This 
# value is a '&' separated list of ',' separate triples.  For example, 
#     configs=win32,win32,x86 & linux,motif,x86
# By default the value is *,*,*

My proposed fix is the following:

private static boolean isMatching(String candidateValues, String siteValues) {
	if (siteValues == null)
		return false;
	if ("*".equals(siteValues))return true; // ADD THIS LINE 
	if ("*".equals(candidateValues))return true; //$NON-NLS-1$
	if ("".equals(candidateValues))return true; //$NON-NLS-1$
	StringTokenizer siteTokens = new StringTokenizer(siteValues, ","); //$NON-NLS-1$

	while (siteTokens.hasMoreTokens()) {
		StringTokenizer candidateTokens = new StringTokenizer(candidateValues, ","); //$NON-NLS-1$
		String siteValue = siteTokens.nextToken();
		while (candidateTokens.hasMoreTokens()) {
			if (siteValue.equalsIgnoreCase(candidateTokens.nextToken()))
				return true;
		}
	}
	return false;
}

I had a quick look at 3.5.2, 3.8.1, 4.2.1 and the code is the same.
Comment 1 Andrew Niefer CLA 2013-02-07 09:38:15 EST
This is working as designed, the "*"  value is not a wild card, it should be interpreted as "all" and not "any".  It means bundles/fragments that are platform independent.

If there is anything to be done here, it is documentation to make this more explicit and clear.
Comment 2 Nikolas Falco CLA 2013-02-07 10:27:47 EST
Ok it was a misunderstanding, I interpreted wildcards as usual (any value), due also name of artifacts producted in buildDirectory are:
- finalFeaturesVersions.ANY_ANY_ANY.properties
- finalPluginsVersions.ANY_ANY_ANY.properties
Comment 3 Andrew Niefer CLA 2013-02-07 11:10:04 EST
This has historically been a common misconception.  The comment in the templates/headless-build/build.properties file should be clarified, as well as the help docs.

I think whether or not "any" makes sense depends a little on the perspective:
this config accepts bundles that will install on any platform
vs
this config will accept any bundle
Comment 4 Lars Vogel CLA 2018-12-03 09:05:52 EST
Currently we are not actively enhancing PDE build anymore. Therefore, I close this bug as WONTFIX. 

Please reopen, if you plan to provide a fix.