I think for the moment that we should follow
matt's idea of not setting ant.file.x if there is
no name="" in the <project> tag. This will
follow the principal of least suprise, and will
obey the principal for not silently overwriting
properties.
On 10/5/06, Matt Benson <[EMAIL PROTECTED]> wrote:
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > > > The user's omission of the project> name
> > > > implies consent to this.
> > > Not quite. [...]
> > I still don't see how this conflicts with my
> > earlier statement.
>
> Where I disagree is that you assume the imported
> build writer is the
> same as the importer build writer (the user or
> client in other words).
> As a client, I shouldn't have to care whether the
> project is named or
> not, and be able to manipulate and reference the
> build I import on my
> terms, not his terms.
Point. However, in such a case it would not make
sense for the provider of the imported file not to use
a project name. Was there a reason not to support
"as"? It sounds like a trivial change. If we
supported "as", we could bypass storing project-name
stuff for <import> unless "as" is specified, printing
a warning as well. Then we change the documentation
to recommend the use of the "as" attribute, with your
explanation as to why it is preferable.
I do not like the use of "as". <import> should be simple
to use and should "just work".
When we implement multi file import, what should "as" be?
I do not like use of properties for things that are handled in
C by the macro __FILE__ : perhaps we could use a task,
or a ${ant.current.file:} function?
Peter
-Matt
>
> This is why it's still so difficult to write truly
> generic build
> files, despite <import>. Not enough
> compartimentalization, and mixing
> of concerns. --DD
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
