Home » Archived » Buckminster » 'No component match was found' error - Resolve to Wizard
|
| Re: 'No component match was found' error - Resolve to Wizard [message #378255 is a reply to message #378246] |
Wed, 02 July 2008 18:07   |
|
Claus Klammer wrote:
> I have version match problems when trying to resolve a product. The
> product references features:
>
> <features>
> <feature id="feature1" version="1.3.1.qualifier"/>
> <feature id="feature2" version="1.3.1.qualifier"/>
> </features>
>
> The version designator settings have not been changed -> all versions
> should be accepted. But 'Resolve to Wizard' in the Component Query
> Editor causes a 'no component match was found' error.
>
> feature1/[1.3.1,1.3.1]#OSGi: Rejecting provider
> eclipse.platform(feature/${buckminster.component}): No component match
> was found
>
This is natural. 1.3.1.qualifier can never be exactly the same as 1.3.1
so a perfect match request is not feasible here.
> Even if I set the Version designator to '>= 1.3.1' the same error occurs.
>
This however, should work. What does the error message look like when
you do this?
What is the exact version of the feature in question in your target
platform?
Regards,
Thomas Hallgren
|
|
| |
| Re: 'No component match was found' error - Resolve to Wizard [message #378521 is a reply to message #378507] |
Tue, 15 July 2008 07:31 |
|
Claus Klammer wrote:
> Then the default behaviour must have been changed in the last few weeks,
> because with an older version with the same settings all versions were
> accepted.
>
The behavior might have changed due to this bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=238779 but it should not
result in the behavior that you are experiencing.
> I assume you're talking about the feature to resolve. The version is
> '1.3.1.qualifier'.
>
> To summarize:
> - version of referenced features of product to resolve is '1.3.1.qualifier'
I'm not sure what you are saying here. Do you have a feature that in
turn includes another feature?
> - cquery without version entry that worked a few weeks ago:
> <cq:rootRequest name="this.is.a.product"/>
> - resulting error message which pretends to search for a feature with
> the exact version match '1.3.1': feature1/[1.3.1,1.3.1]#OSGi: Rejecting
> provider....
So where do the 1.3.1 come from? If it isn't in the query, it must be in
something that the query resolves that in turn references something else.
> - removing the version tag from the referenced feature entries in the
> .product file fixes problem (this was not necessary before and it breaks
> normal eclipse product export)
>
Do you have a product that in turn includes several features? I can see
how that would break your setup. Buckminster doesn't really treat the
product as a top-level component definition since a component can
contain any number of product definition files. That doesn't mean it
shouldn't work of course, just that it's not very well tested.
The recommended setup for Buckminster is to use one single feature to
describe the product. This feature in turn can include other features
and plug-ins (as opposed to the product itself which can contain only
features OR plug-ins).
I wrote a blog-entry on this a while back where I outline this approach.
http://thhal.blogspot.com/2008/01/product-configurations.htm l
> Let me know what's the default behaviour if no version is set in the
> version designator now.
>
If no version is set in a feature reference present in a product
configuration, then the dependency should resolve to the highest version
available.
Regards,
Thomas Hallgren
|
|
|
| Re: 'No component match was found' error - Resolve to Wizard [message #378523 is a reply to message #378521] |
Tue, 15 July 2008 09:03 |
 Claus Klammer
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
To clarify how the .product file configuration looks like, below you
find the the interesting configuration parts:
<product name="%Product.name" id="product" application="application"
version="1.3.1" useFeatures="true">
.....
<features>
<feature id="feature1" version="1.3.1.qualifier"/>
<feature id="feature2" version="1.3.1.qualifier"/>
<feature id="feature3" version="1.3.1.qualifier"/>
</features>
....
As I wrote in the previous message removing the 'version' tag from the
feature references solves the issue but then the internal eclipse
product export does not work anymore.
I'm sure that the bug fix 238779 causes my troubles since the required
version match is set to a specific value now. But it seams that
'qualifier' is ignored for feature references defined within a .product
file. Instead of expected required reference match [1.3.1.qualifier,
1.3.1.qualifier] the search for features is limited to [1.3.1,1.3.1]!
Should I file this as a bug?
In the meantime I will try to use a feature definition as top level
component instead.
Regards,
Claus Klammer
Thomas Hallgren schrieb:
> Claus Klammer wrote:
>
>> Then the default behaviour must have been changed in the last few weeks,
>> because with an older version with the same settings all versions were
>> accepted.
>>
> The behavior might have changed due to this bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=238779 but it should not
> result in the behavior that you are experiencing.
>
>> I assume you're talking about the feature to resolve. The version is
>> '1.3.1.qualifier'.
>>
>> To summarize:
>> - version of referenced features of product to resolve is
>> '1.3.1.qualifier'
>
> I'm not sure what you are saying here. Do you have a feature that in
> turn includes another feature?
>
>> - cquery without version entry that worked a few weeks ago:
>> <cq:rootRequest name="this.is.a.product"/>
>> - resulting error message which pretends to search for a feature with
>> the exact version match '1.3.1': feature1/[1.3.1,1.3.1]#OSGi: Rejecting
>> provider....
>
> So where do the 1.3.1 come from? If it isn't in the query, it must be in
> something that the query resolves that in turn references something else.
>
>> - removing the version tag from the referenced feature entries in the
>> .product file fixes problem (this was not necessary before and it breaks
>> normal eclipse product export)
>>
> Do you have a product that in turn includes several features? I can see
> how that would break your setup. Buckminster doesn't really treat the
> product as a top-level component definition since a component can
> contain any number of product definition files. That doesn't mean it
> shouldn't work of course, just that it's not very well tested.
>
> The recommended setup for Buckminster is to use one single feature to
> describe the product. This feature in turn can include other features
> and plug-ins (as opposed to the product itself which can contain only
> features OR plug-ins).
>
> I wrote a blog-entry on this a while back where I outline this approach.
>
> http://thhal.blogspot.com/2008/01/product-configurations.htm l
>
>
>> Let me know what's the default behaviour if no version is set in the
>> version designator now.
>>
> If no version is set in a feature reference present in a product
> configuration, then the dependency should resolve to the highest version
> available.
>
> Regards,
> Thomas Hallgren
|
|
|
| Re: 'No component match was found' error - Resolve to Wizard [message #378525 is a reply to message #378523] |
Tue, 15 July 2008 09:05 |
Claus Klammer
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
--- forward answer to newsgroup -------
Claus Klammer wrote:
> To clarify how the .product file configuration looks like, below you
find the the interesting configuration parts:
>
> <product name="%Product.name" id="product" application="application"
version="1.3.1" useFeatures="true">
> ....
> <features>
> <feature id="feature1" version="1.3.1.qualifier"/>
> <feature id="feature2" version="1.3.1.qualifier"/>
> <feature id="feature3" version="1.3.1.qualifier"/>
> </features>
> ...
>
> As I wrote in the previous message removing the 'version' tag from
the feature references solves the issue but then the internal eclipse
product export does not work anymore.
>
> I'm sure that the bug fix 238779 causes my troubles since the
required version match is set to a specific value now. But it seams that
'qualifier' is ignored for feature references defined within a .product
file. Instead of expected required reference match [1.3.1.qualifier,
1.3.1.qualifier] the search for features is limited to [1.3.1,1.3.1]!
Should I file this as a bug?
>
Yes, please file this as a bug. Transforming it to an explicit version
range is not correct unless the qualifier is indeed expanded. If the
keyword 'qualifier' is used, the generated version range should match
any version that has a qualifier defined, i.e.
1.3.1.qualifier becomes [1.3.1.0,1.3.2)
Qualifier comparison uses natural sort order so a qualifier of '0' is
hard to beat.
Regards,
Thomas Hallgren
Claus Klammer schrieb:
> To clarify how the .product file configuration looks like, below you
> find the the interesting configuration parts:
>
> <product name="%Product.name" id="product" application="application"
> version="1.3.1" useFeatures="true">
> ....
> <features>
> <feature id="feature1" version="1.3.1.qualifier"/>
> <feature id="feature2" version="1.3.1.qualifier"/>
> <feature id="feature3" version="1.3.1.qualifier"/>
> </features>
> ...
>
> As I wrote in the previous message removing the 'version' tag from the
> feature references solves the issue but then the internal eclipse
> product export does not work anymore.
>
> I'm sure that the bug fix 238779 causes my troubles since the required
> version match is set to a specific value now. But it seams that
> 'qualifier' is ignored for feature references defined within a .product
> file. Instead of expected required reference match [1.3.1.qualifier,
> 1.3.1.qualifier] the search for features is limited to [1.3.1,1.3.1]!
> Should I file this as a bug?
>
> In the meantime I will try to use a feature definition as top level
> component instead.
>
> Regards,
> Claus Klammer
>
> Thomas Hallgren schrieb:
>> Claus Klammer wrote:
>>
>>> Then the default behaviour must have been changed in the last few weeks,
>>> because with an older version with the same settings all versions were
>>> accepted.
>>>
>> The behavior might have changed due to this bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=238779 but it should not
>> result in the behavior that you are experiencing.
>>
>>> I assume you're talking about the feature to resolve. The version is
>>> '1.3.1.qualifier'.
>>>
>>> To summarize:
>>> - version of referenced features of product to resolve is
>>> '1.3.1.qualifier'
>>
>> I'm not sure what you are saying here. Do you have a feature that in
>> turn includes another feature?
>>
>>> - cquery without version entry that worked a few weeks ago:
>>> <cq:rootRequest name="this.is.a.product"/>
>>> - resulting error message which pretends to search for a feature with
>>> the exact version match '1.3.1': feature1/[1.3.1,1.3.1]#OSGi: Rejecting
>>> provider....
>>
>> So where do the 1.3.1 come from? If it isn't in the query, it must be
>> in something that the query resolves that in turn references something
>> else.
>>
>>> - removing the version tag from the referenced feature entries in the
>>> .product file fixes problem (this was not necessary before and it breaks
>>> normal eclipse product export)
>>>
>> Do you have a product that in turn includes several features? I can
>> see how that would break your setup. Buckminster doesn't really treat
>> the product as a top-level component definition since a component can
>> contain any number of product definition files. That doesn't mean it
>> shouldn't work of course, just that it's not very well tested.
>>
>> The recommended setup for Buckminster is to use one single feature to
>> describe the product. This feature in turn can include other features
>> and plug-ins (as opposed to the product itself which can contain only
>> features OR plug-ins).
>>
>> I wrote a blog-entry on this a while back where I outline this approach.
>>
>> http://thhal.blogspot.com/2008/01/product-configurations.htm l
>>
>>
>>> Let me know what's the default behaviour if no version is set in the
>>> version designator now.
>>>
>> If no version is set in a feature reference present in a product
>> configuration, then the dependency should resolve to the highest
>> version available.
>>
>> Regards,
>> Thomas Hallgren
|
|
|
| Re: 'No component match was found' error - Resolve to Wizard [message #378529 is a reply to message #378525] |
Tue, 15 July 2008 09:15 |
Claus Klammer
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
filed bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=240783
cheers,
Claus
Claus Klammer schrieb:
> --- forward answer to newsgroup -------
>
> Claus Klammer wrote:
> > To clarify how the .product file configuration looks like, below you
> find the the interesting configuration parts:
> >
> > <product name="%Product.name" id="product" application="application"
> version="1.3.1" useFeatures="true">
> > ....
> > <features>
> > <feature id="feature1" version="1.3.1.qualifier"/>
> > <feature id="feature2" version="1.3.1.qualifier"/>
> > <feature id="feature3" version="1.3.1.qualifier"/>
> > </features>
> > ...
> >
> > As I wrote in the previous message removing the 'version' tag from
> the feature references solves the issue but then the internal eclipse
> product export does not work anymore.
> >
> > I'm sure that the bug fix 238779 causes my troubles since the
> required version match is set to a specific value now. But it seams that
> 'qualifier' is ignored for feature references defined within a .product
> file. Instead of expected required reference match [1.3.1.qualifier,
> 1.3.1.qualifier] the search for features is limited to [1.3.1,1.3.1]!
> Should I file this as a bug?
> >
> Yes, please file this as a bug. Transforming it to an explicit version
> range is not correct unless the qualifier is indeed expanded. If the
> keyword 'qualifier' is used, the generated version range should match
> any version that has a qualifier defined, i.e.
>
> 1.3.1.qualifier becomes [1.3.1.0,1.3.2)
>
> Qualifier comparison uses natural sort order so a qualifier of '0' is
> hard to beat.
>
> Regards,
> Thomas Hallgren
>
>
> Claus Klammer schrieb:
>> To clarify how the .product file configuration looks like, below you
>> find the the interesting configuration parts:
>>
>> <product name="%Product.name" id="product" application="application"
>> version="1.3.1" useFeatures="true">
>> ....
>> <features>
>> <feature id="feature1" version="1.3.1.qualifier"/>
>> <feature id="feature2" version="1.3.1.qualifier"/>
>> <feature id="feature3" version="1.3.1.qualifier"/>
>> </features>
>> ...
>>
>> As I wrote in the previous message removing the 'version' tag from the
>> feature references solves the issue but then the internal eclipse
>> product export does not work anymore.
>>
>> I'm sure that the bug fix 238779 causes my troubles since the required
>> version match is set to a specific value now. But it seams that
>> 'qualifier' is ignored for feature references defined within a .product
>> file. Instead of expected required reference match [1.3.1.qualifier,
>> 1.3.1.qualifier] the search for features is limited to [1.3.1,1.3.1]!
>> Should I file this as a bug?
>>
>> In the meantime I will try to use a feature definition as top level
>> component instead.
>>
>> Regards,
>> Claus Klammer
>>
>> Thomas Hallgren schrieb:
>>> Claus Klammer wrote:
>>>
>>>> Then the default behaviour must have been changed in the last few
>>>> weeks,
>>>> because with an older version with the same settings all versions were
>>>> accepted.
>>>>
>>> The behavior might have changed due to this bug
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=238779 but it should
>>> not result in the behavior that you are experiencing.
>>>
>>>> I assume you're talking about the feature to resolve. The version is
>>>> '1.3.1.qualifier'.
>>>>
>>>> To summarize:
>>>> - version of referenced features of product to resolve is
>>>> '1.3.1.qualifier'
>>>
>>> I'm not sure what you are saying here. Do you have a feature that in
>>> turn includes another feature?
>>>
>>>> - cquery without version entry that worked a few weeks ago:
>>>> <cq:rootRequest name="this.is.a.product"/>
>>>> - resulting error message which pretends to search for a feature with
>>>> the exact version match '1.3.1': feature1/[1.3.1,1.3.1]#OSGi: Rejecting
>>>> provider....
>>>
>>> So where do the 1.3.1 come from? If it isn't in the query, it must be
>>> in something that the query resolves that in turn references
>>> something else.
>>>
>>>> - removing the version tag from the referenced feature entries in the
>>>> .product file fixes problem (this was not necessary before and it
>>>> breaks
>>>> normal eclipse product export)
>>>>
>>> Do you have a product that in turn includes several features? I can
>>> see how that would break your setup. Buckminster doesn't really treat
>>> the product as a top-level component definition since a component can
>>> contain any number of product definition files. That doesn't mean it
>>> shouldn't work of course, just that it's not very well tested.
>>>
>>> The recommended setup for Buckminster is to use one single feature to
>>> describe the product. This feature in turn can include other features
>>> and plug-ins (as opposed to the product itself which can contain only
>>> features OR plug-ins).
>>>
>>> I wrote a blog-entry on this a while back where I outline this approach.
>>>
>>> http://thhal.blogspot.com/2008/01/product-configurations.htm l
>>>
>>>
>>>> Let me know what's the default behaviour if no version is set in the
>>>> version designator now.
>>>>
>>> If no version is set in a feature reference present in a product
>>> configuration, then the dependency should resolve to the highest
>>> version available.
>>>
>>> Regards,
>>> Thomas Hallgren
|
|
|
Goto Forum:
Current Time: Mon Sep 23 22:19:33 GMT 2024
Powered by FUDForum. Page generated in 0.04439 seconds |
] 
Search
Help
Register
Login
Home
