> 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="xxx.properties"/>
> <propfile name="xxx-${java.os}-${java.arch}.properties"/>
> <propfile name="~/.xxx.properties"/>
Agreed.
> 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.
Proposal:
- 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.
- Property.java 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.
Costin
|