Community
Participate
Working Groups
When you materialize a component, you provide (in the CQuery) a component name, and a component type (eclipse.feature, osgi.bundle etc.). Importantly, the componentType is optional. The Resource Map contains provider entries that look like this: <rm:provider componentTypes="osgi.bundle" readerType="git"> ... stuff ... </rm:provider> The rules for resolution: (1) *IF* the CQuery specifies componentType then, in the RMap, it filters based on the provider componentTypes - only providers where CQuery componentType is one of the provider componentTypes are looked at. (2) If the CQuery *DID NOT* specify componentType then, in the RMap, it does not filter based on provider componentTypes, but looks at all providers. Well, the rules are almost followed. However, when the provider type is "p2", it doesn't work - if the CQuery does not specify componentType, then the component is not resolved. It correctly ignores the RMap componentTypes, but doesn't actually find the component. You get a message like this: Rejecting provider p2(${pydev.download.url}/3.0.0-opengda/[http://dawn.diamond.ac.uk/updates/pydev/3.0.0-opengda/]): No component match was found I have observed this problem with Buckminster 4.2 IDE and headless, and 3.7 headless (3.7 IDE not tested).
I would argue that the componentType isn't optional at all. If you don't specify what you're looking for, how can you expect Buckminster to find it?
>> I would argue that the componentType isn't optional at all **** I agree that it probably shouldn't be optional, but it looks like it was intended to be: cquery-1.0.xsd <attribute name="componentType" type="string" use="optional"><annotation><documentation> If set, this advisor node will only match requests that has this component type. </documentation></annotation></attribute> From rmap-1.0.xsd <attribute name="componentTypes" type="string" use="optional"><annotation><documentation> The provider will only handle requests that have no component type defined or a component type that matches one of the types listed here. At least one type must be listed. </documentation></annotation></attribute> **** Perhaps it's best if I explain my use case. Our developers use a standard fairly complex CQuery we have (lots of advisor nodes etc., it's at http://www.opengda.org/buckminster/base/dawn-master.cquery if you want to take a look). The key part of the CQuery is this: <cq:rootRequest name="${component}"/> Note that a name is specified, but no componentType. If a developer wants to materialize something from within their IDE, they open the CQuery, overtype ${component} with the name of whatever they want, then (sometimes) select an entry from the "Component Type:" box, and materialize. This works well, and interestingly if nothing is selected in the "Component Type:" box, it still works UNLESS the component in question is found in a p2 provider. That is not a problem, since the developer can always select a specific "Component Type:". Then there is the case when we materialize something using headless Buckminster. To specify the component name, we specify the property "component=<name>" (this is actually done by a script to make it easy). We end up calling headless buckminster and issuing an "import" command. Again, this works well, but notice that we never specify the component type. As for the IDE, this works UNLESS the component in question is found in a p2 provider. The problem is in the headless case. There is no way I could find to specify the componentType: (1)Setting a property such as componentType or buckminster.componentType doesn't work. (2) Changing the CQuery to the (invalid) <cq:rootRequest name="${component}" componentType="${componentType}"/> doesn't work either, Bucky drops the invalid componentType when it loads the CQuery. **** So, my problem is that the headless Buckminster "import" command only takes the URL of a CQuery (etc.) for an argument. You can then, using properties, override the component name in the CQuery, but there is no way to specify or override the component type. I have to say this is _not_ a major problem for us. We have used this system for a long time without problems, since the "no component type specified" case mostly works (except for p2 providers). We only found this problem recently, and fortunately don't expect it to happen too often (mostly, the *parent* component we want to materialize is in a source repo and not a p2 site). It would be nice if it worked, though, but I don't see any straightforward solution.
>> If you don't specify what you're looking for, how can you expect Buckminster to find it? I know what I am looking for - component name and component type - but (in headless buckminster) can only specify the component name. In my case this is ok since there is only one component with the given name, but it's true that you can have the multiple components of the same name if their type is different. For normal source repos, Buckminster will find some component with the same name and materialize that. For p2 providers, it needs to know what type it is looking for.
I need to correct an error in comment 2: I stated that cquery-1.0.xsd showed componentType was optional. In fact, the snippet I showed was from the advisor node, which is not relevant here. The CQuery specifies <element name="rootRequest" type="cs:ComponentRequest" minOccurs="1" maxOccurs="1" /> where ComponentRequest is in cspec-1.0.xsd <attribute name="componentType" type="string" use="optional"><annotation><documentation> The component type, if any, of the required component. </documentation></annotation></attribute>
