[buckminster-dev] Re: Components that come into existence during a build

["Henrik Lindberg" <glashammer@xxxxxxxxxxx>]

I like the idea that generated components are subcomponents of a real 
component.

It would be great to be able to use the same type of naming as in java, just 
add ".subcomponent" to the name of the partent component to find it.
Understand that this is somewht more problematic since components are 
distributed and it is far better to know in advance that a subcomponent is 
wanted then to first search for the full component name 
"x.y.sdk.feature.source" and fail, and then see if "x.y.sdk.feature" has a 
subcomponent called "source". If we can use such a scheme, you would only 
state the dependency to the subcomponent, just as you would with any other 
component. All the definitions are in the parent of the subcomponent. 
(Better component encapsulation).

However, I guess that in a world of million options, some projects may need 
to structure things so that a parent component creates components named 
completely disjunct from the parents name. component "x.y.z" produces 
"a.source". Naturally such a naming scheme is more confusing, but should be 
handled by Buckminster.

then this could be stated as:
<cs:dependency name="the.subcomponent.name" 
subcomponentOf="the.parent.component">

Which is the same as your last example, but with a different name for the 
"producedBy" attribute.  If you want something short, why not:
<cs:dependency name="the.subcomponent.name" in="the.parent.component">

How do you suggest the declaration of a subcomponent is made in the parent 
component?

- henrik

"Thomas Hallgren" <thomas@xxxxxxx> skrev i meddelandet 
news:451CC66E.30204@xxxxxxx...
> Thomas Hallgren wrote:
>> Some features may refer to components that themselves are products from a 
>> build. Eclipse source plugins for instance, cannot be "found and 
>> materialized" in a traditional sense because they are created on the fly. 
>> Question is, how is this best handled in Buckminster? Let's assume a top 
>> level feature. 'x.y.sdk.feature' that has a reference to the plugin 
>> 'x.y.source'. This plugin is created by copying all source from the 
>> plugins x.y.a and x.y.b.
>>
>> The easy way to handle this is of course to create the x.y.source feature 
>> and add a cspec to it that performs the rest. But if we do that, we 
>> create an artifact that has no other meaning then to assist in the build 
>> process. I'm now looking at the BIRT project and they create all source 
>> plugins on the fly. IMHO, we should be able to do that too.
>>
>> An easy way to accomplish this is perhaps to use a 'prebind' action in 
>> the controlling feature. The action creates the needed artifacts. The 
>> only thing left after that is to bind them to the workspace. We could 
>> have an ant-task that communicates this to the our internal binder.
>>
>> Thoughs?
>>
> One thing that needs to be added to this proposal is that there must be a 
> way to reference the components that are created. Since they in fact are 
> created by another component, a normal reference will not suffice. 
> Buckminster cannot find it if it doesn't exist. Someone must know how it 
> comes into existence.
>
> One idea is to require that dependencies to such components must go 
> through a dependency to the component that created them. In the cspec, the 
> would mean that we extend the <dependency> element like so:
>
>     <cs:dependency name="x.y.sdk.feature">
>         <cs:generates name="x.y.source"/>
>     </cs:dependency>
>
> Alternatively, we could turn things in side out and do something like 
> this:
>
>     <cs:dependency name="x.y.source" generatedBy="x.y.sdk.feature"/>
>
> Regards,
> Thomas Hallgren