ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <peter.kitt.rei...@gmail.com>
Subject Re: ant.file.{projectname} property
Date Thu, 05 Oct 2006 20:09:47 GMT
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 <gudnabrsam@yahoo.com> wrote:
> --- Dominique Devienne <ddevienne@gmail.com> 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:
> > dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail:
> > dev-help@ant.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message