[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] Action properties [WAS Action output?]
|
Kenneth Ölwing wrote:
'Inherited' properties is great and something we could/should have, I
agree. Actually, I think inherited is the wrong word, it's more
'arguments' to an action. We should talk more of actual definition of
how it should work. For example, when thinking about your example
below, I'm worried that it opens up another can of worms, as in when
and in what order properties are resolved in order for them to be
resolvable like that at the proper time.
We did talk a great deal about this last spring. It resulted in this UML
diagram:
http://wiki.tada.se/wiki/download/attachments/256/org.eclipse.buckminster.model.cspec.jpg?version=1
It brings in 'component variability' and our discussion has in some
sense diverged into that area. The requirement properties I used in my
example (or arguments that you choose to call it) maps very well to the
'RequiredValue'. Thinking a bit more about it, I'm inclined to retract
what my example proposed. More below...
Small note: the local should be an external, right?
Oops. Looks like I simplified it a bit :-) The example still contains
whats needed to describe the problem I think.
And, this is important: I actually I screwed up my example a bit - A
was 'myself' which I *did* have control over - I was actually meaning
that *C* had a coolselector that should get cool_c_stuff...sorry.
Though the problem might actually be technically solvable this way
anyhow. Maybe my error about confusing A and C changes your picture,
but I'll just make the rest of the argument anyway....
While this *technically* solves the problem, I don't really care for
it (except for the general usefulness of being able to pass props to
other actions). One reason is that it is just a workaround for a
*fundamental* problem we have created in the first place by *not*
providing property isolation. Another reason is that it places the
burden on 'me' (A) to fix issues between B and C. Or any other action
ever that has the same dependency to B (and then C). Finally, this
assumes that I'm fully aware of the problem with this property, the
consequences and the proper solution (*workaround*).
That all seems silly to me.
I'm a bit confused here. Are you saying that C also has a coolselector?
If that's the case, then surely the author of B must address that since
B uses a property with the same name. In some respect that's part of B's
responsibility to encapsulate C. Unless A has a direct dependency to C,
it should not know anything about it. If it has a direct dependency then
it must follow the property redirect rules stipulated (and made public)
by B. I don't see a fundamental problem, nor any workarounds.
And further, avoiding technical solutions for a second, just think
about 'the philosophy'. We spend a lot of time working with making
sure components otherwise are isolated from each other, we deal with
namespaces and all the other ways to *help* users avoid making
mistakes. True, we can't handle all cases, but in this case I have yet
to see a good argument as to why we should suddenly throw that mindset
to the winds. You say 'KISS', and that the use-case is 'uncommon'. If
we would have stayed with KISS, there's a lot of things we could do
much, much simpler (and much more error-prone). There's another
saying: 'keep it as simple as possible, but no simpler' - i.e. if we
have to do a bit more (and not much in my opinion) to avoid what I
believe is a very real(istic) problem, then that's better for everyone
in the end. Even if a commandline get's a bit icky...
What I mean is uncommon is the case where you need to pass different
*runtime* properties to different actions in the same invocation. We do
need to introduce the variability that and the ability to qualify
requirements that we outlined in the diagram but I'm perfectly happy to
make that the next step and to postpone the discussion about runtime
injection into such variables. Once that's in place, perhaps we have
another view of the need to influence the mechanism in runtime.
As for component isolation, yes absolutely. Passing of 'properties',
'arguments', or 'variables' must be a very controlled process and it
cannot use arbitrary names either. The variability will be about things
like operating system, java version, debug versus optimized, etc. They
will be part of (and indeed modify) the requirement (and hence the
expected import) so that if A and B are both dependent on C but uses
different variables in their requirements, then C must be built twice
and cater for that it's output ends up in different sub-folders (just an
example that highlights the need for more elaborated design details).
Situations where name conflicts occur may of course arise anyway so
whatever we come up with must be able to deal with that.
An attempt to conclude (for now):
When we say 'properties' henceforth, can we agree that it's a fairly
crude way of passing arguments to a build process and perhaps also agree
that there's only one global property set and that the context/action
properties will act as overlays on that set?
- thomas
