Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 331754 - Binary bundle ends up in workspace (url reader type)
Summary: Binary bundle ends up in workspace (url reader type)
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Buckminster (show other bugs)
Version: unspecified   Edit
Hardware: Macintosh Mac OS X
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: buckminster.core-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-03 04:56 EST by Peter Kullmann CLA
Modified: 2019-02-25 14:39 EST (History)
2 users (show)

See Also:


Attachments
Patch to materialize binary components with p2 (1.60 KB, patch)
2010-12-23 16:03 EST, Alan Underwood CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Kullmann CLA 2010-12-03 04:56:13 EST
This is from the mailing list (see the end of the thread): http://www.eclipse.org/forums/index.php?t=msg&goto=642724&S=0f94b3cacd0bbc574574a2d3ee8e99d9

I was importing com.springsource.com.sun.jna from the springsource repository using a url reader. The bundle ends up in the workspace but should really be in the target. Thomas thinks it might be an error in the url reader.

This is the relevant part of the rmap:
<searchPath name="com.springsource.com.sun.jna">
 <provider readerType="url" componentTypes="osgi.bundle"
           mutable="false" source="false">
  <uri

format="http://repository.springsource.com/ivy/bundles/external/net.java.dev.jna/{1}/{2}/{1}-{2}.jar">
   <bc:replace pattern="com\.springsource\.(.*)" replacement="$1">
    <bc:propertyRef key="buckminster.component" />
   </bc:replace>
   <bc:propertyRef key="buckminster.component" />
   <bc:replace pattern=".*([0-9]+\.[0-9]+\.[0-9]+).*" replacement="$1">
    <bc:propertyRef key="buckminster.version.designator" />
   </bc:replace>
  </uri>
 </provider>
</searchPath>

The query was to com.springsource.com.sun.jna, version == "3.2.3". Buckminster puts it into the workspace and I have no clue why. I could solve it by using an mspec that materializes com.springsource.* with the p2 materializer. With that everything works well.
Comment 1 Alan Underwood CLA 2010-12-22 14:04:39 EST
I think this a a problem in org.eclipse.buckminster.core/src/java/org/eclipse/buckminster/core/mspec/model/MaterializationSpec.java

public String getMaterializerID(Resolution resolution) throws CoreException {
 IMaterializationNode node = getMatchingNode(resolution);
 String materializer = (node == null) ? null : node.getMaterializerID();
 if (materializer == null) {
  materializer = getMaterializerID();
  if (materializer == null)
   materializer = resolution.getProvider()
         .getReaderType().getRecommendedMaterializer();
 }
 return materializer;
}

If you go with the default materialization then materializer == null in both tests.
The URLReaderType delegates to its super class (AbstractReaderType) for getRecommendedMaterializer() which returns IMaterializer.WORKSPACE.

There is no check for source="false" or for componentType="osgi.bundle" OR "eclipse.feature".

If I get the chance I'll submit a patch for this for review.
Comment 2 Alan Underwood CLA 2010-12-23 16:03:56 EST
Created attachment 185792 [details]
Patch to materialize binary components with p2

This patch checks the component resolved is binary and either eclipse.feature or osgi.bundle. If so it specifies the p2 materializer.
Comment 3 Thomas Hallgren CLA 2011-01-24 07:41:14 EST
I committed a slightly modified version where I added a parenthesis around the || terms in the if statement since && has higher precedence.

Thanks for the patch. It's now committed to the helios-maintenance branch, rev 11625.
Comment 4 Thomas Hallgren CLA 2011-01-24 16:32:15 EST
.