|
| Re: Ignoring product file in plugin project [message #380384 is a reply to message #380383] |
Thu, 09 October 2008 06:31   |
|
Hi Carsten,
There is presently no way of excluding meta-data files that Buckminster locates and the
only way to skip components today is by using advisory nodes. I'm happy to discuss ways to
improve this with you if you have ideas on how it could be made.
Regards,
Thomas Hallgren
Carsten Reckord wrote:
> Hi folks,
>
> I've been banging my head on one CQuery for quite some time now because
> it tries to materialize a ton of stuff it shouldn't and I didn't
> understand why. The query is for a eclipse.feature and as it turns out,
> one of the plugins included in the feature contains a foo.product file
> in its root directory, that somehow triggers materialization of all the
> product plugins.
>
> Is there an easy way (either in the CQuery or with a CSpex) to tell
> Buckminster to ignore that product definition? I do not want to manually
> exclude each plugin from the product with an Advisory...
>
>
> thanks,
> Carsten
|
|
|
| Re: Ignoring product file in plugin project [message #380385 is a reply to message #380384] |
Thu, 09 October 2008 10:01 |
 Carsten Reckord
Messages: 139
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas,
I probably should begin with the disclaimer that I'm still finding my way into Buckminster and still struggling with the intricacies of what
happens when and why in the materialization process.
That said, I was really surprised that a product file in an otherwise plain plug-in/osgi-bundle project was considered meta-data for that
bundle, since bundle meta-data and product spec meta-data are only very loosely related (in fact in this case this was apparently just a
convenient place to put the file).
Therefore, the first idea that came to mind was to have a component type eclipse.product to discern between a product spec as an artifact -
or component - in its own right and another component hosted in the same project, like an osgi bundle or a feature. This way, when the
component is resolved as an osgi.bundle, only the bundle meta-data would be taken into account and when it is resolved as an
eclipse.product, only the product specification is used. Or at least the eclipse.product type could be used in an advisory node to skip the
product spec using its product id.
Regards,
Carsten
On 09.10.2008 08:31, Thomas Hallgren wrote:
> Hi Carsten,
> There is presently no way of excluding meta-data files that Buckminster locates and the
> only way to skip components today is by using advisory nodes. I'm happy to discuss ways to
> improve this with you if you have ideas on how it could be made.
>
> Regards,
> Thomas Hallgren
>
> Carsten Reckord wrote:
>> Hi folks,
>>
>> I've been banging my head on one CQuery for quite some time now because
>> it tries to materialize a ton of stuff it shouldn't and I didn't
>> understand why. The query is for a eclipse.feature and as it turns out,
>> one of the plugins included in the feature contains a foo.product file
>> in its root directory, that somehow triggers materialization of all the
>> product plugins.
>>
>> Is there an easy way (either in the CQuery or with a CSpex) to tell
>> Buckminster to ignore that product definition? I do not want to manually
>> exclude each plugin from the product with an Advisory...
>>
>>
>> thanks,
>> Carsten
|
|
|
| Re: Ignoring product file in plugin project [message #380386 is a reply to message #380385] |
Thu, 09 October 2008 14:22 |
|
Hi Carsten,
Some answers inline.
Carsten Reckord wrote:
> I was really surprised that a product file in an otherwise plain
> plug-in/osgi-bundle project was considered meta-data for that bundle,
> since bundle meta-data and product spec meta-data are only very
> loosely related (in fact in this case this was apparently just a
> convenient place to put the file).
>
The rationale for this is that in order to build the product(s) you need
to resolve the dependencies. I can agree that there are cases when this
is of no interest but I would argue that they are fairly rare.
> Therefore, the first idea that came to mind was to have a component
> type eclipse.product to discern between a product spec as an artifact
> - or component - in its own right and another component hosted in the
> same project, like an osgi bundle or a feature. This way, when the
> component is resolved as an osgi.bundle, only the bundle meta-data
> would be taken into account and when it is resolved as an
> eclipse.product, only the product specification is used. Or at least
> the eclipse.product type could be used in an advisory node to skip the
> product spec using its product id.
>
The problem with that approach is that it is common both to place
product files in an eclipse.feature and in an osgi.bundle. The
eclipse.product can hence not be an extension of either one. We would
need two component types in that case. "eclipse.feature.product" and
"eclipse.osgi.product", or in order to be backward compatible
"eclipse.feature.noproduct" and "osgi.bundle.noproduct". Question that
immediately arises though, is how to decide what to use when resolving
dependencies transitively.
One approach would be to add the ability to exclude specific files from
the meta-data generation. The information about what files to exclude
could be entered ni the advisor node. Such a mechanism would be generic
(not Eclipse specific) but it would be a bit cumbersome to use. Another
alternative would be to simply add a check-box to the advisor node
labeled "Ingore Eclipse Product Definitions".
The next problem that occurs is that once you have everything downloaded
it is "alive" in your workspace. When meta-data files are changed, the
cspec is regenerated. No query is involved when that happens.
Regards,
Thomas Hallgren
|
|
|
| Re: Ignoring product file in plugin project [message #380387 is a reply to message #380386] |
Thu, 09 October 2008 15:37 |
Carsten Reckord
Messages: 139
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas,
My rationale for viewing both seperately was that the osgi.bundle does not depend on the product or any of its dependencies beyond the
bundle's own dependencies. And likewise, for the product it doesn't matter whether it "lives" in one of the bundles it includes or in a
completely different project, as long as all of its dependencies can be resolved.
I have to admit that I only looked at the problem from the perspective of the query, where I assumed it would be clear as what (osgi.bundle,
eclipse.feature...) something is resolved. From that point of view, the eclipse.product would not have to be an extension of either, instead
when resolving as eclipse.product, the osgi.bundle or eclipse.feature meta-data could just be ignored, and likewise the product data when
resolving as osgi.bundle or eclipse.feature.
But I can see how that would probably make generating the cspec for the materialized projects "interesting" ;P
For now, I managed to convince the developer of the plugin in question to move the product spec into a sub directory where Buckminster
doesn't look :)
Regards,
Carsten
|
|
|
Powered by
FUDForum. Page generated in 0.03106 seconds
] 
Search
Help
Register
Login
Home
