[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[buckminster-dev] Re: Components that come into existence during a build
|
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
