tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Ant
Date Fri, 10 Dec 1999 19:11:31 GMT
> Isn't this getting too much "tomcat-driven"? I totally understand your
> problems and your solutions and I think they could be great for a tomcat
> builder, but I'm afraid of doing too many things behind my back.

Creating a distribution archive and puting it in a ftp directory is not
tomcat specific. Neither using TSTAMP in the name.

IMHO if a project needs a special Task and it feels like generic
enough - we should just add it.
( like compiling a package only if a class is in classpath - I think
it's something usefull ).

> Something like
> <propfile name=""/>
> <propfile name="xxx-${java.os}-${java.arch}.properties"/>
> <propfile name="~/"/>


> Hmmm, I wonder... we have tasks and we have properties, what we miss is
> a task that generates a property. Something like
>  <property name="stamp" type="timestamp" .../>

What about a task that sets the property ?
I use <dstamp> task, and I plan to add tasks that will look for Apache
and other packaged. ( looking if a class is defined and setting a property
if so might also be usefull).

No need to invent a new mechanism for that.

> Again, I'm _very_ afraid of going in this direction since we loose focus
> on portability. If we had namespace support we could add a sort of
> "taglib", but you don't want to get that complex at this point.

Ok, I guess I was wrong in the first attempt.


- add <target name="init"> and put all initial properties and taskdefs
there.  The code will maintain backward compatiblity, but on long term
it would be nice to migrate the antfiles to this model.

- implements Task will be used instead of a special
code in ProjectHelper. Simpler is better :-)

- <Properties file="name-${os}"> will be used to eliminate
any OS-dependent property.


View raw message