Agreed. I was not the proposer of taskdefs.org-- it was John Casey-- John can you
I would love to see something like this and would happily contribute my task to this sort of distribution. Again, I would like to have it generally available to get feedback and available to me herever I work in a way that I don't have to support those sites in person - having some sort of central repository for contrib tasks would meet my needs. Surely a tiny bit of scoping would be good? www.ant-taskdefs.org?
give us an idea of the status of this?
Excellent ideas. I am afraid our current implementation is rather primitive. You simplyYour propgen task sounds interesting. So how does this work at runtime? I'd really like to see something similar working over JNDI, so I could use property files, ldap or whatever...
pass a "property path" to <propgen> consisting of a colon separated list of files. The properties
from all of these files are combined in the order they appear in the path. The nice feature is
that the properties are first combined, then resolved. This means that properties can be
referenced in one file and defined in another. This is a very important requirement if you
want to avoid duplicating property settings across related projects.
The resulting set of properties is either fully resolved, or
<propgen> craps out complaining of "unresolved properties." If all is well, <propgen>
sets the resulting properties in the current ant project. Alternatively, it can write them
out to a file. Writing them to a file has an important advantage-- <propgen> can test
whether the final set of properties for THIS run is different from that of a PREVIOUS run.
You can tell it not to overwrite the output file if the result is exactly the same as before.
This, combined with tasks such as <dependset>, enables you to correctly require a rebuild
for a project when a property changes. This kind of change might otherwise not be detected
by any of the normal tasks ( <javac>, <style>, etc.)
<target name="init">
<propgen
basedir = "${basedir}"
overwrite = "false"
xmlout = "temp/projecta-output-properties.xml">
<propertypath>
<pathelement path="proposalB-settings.xml:project-settings.xml:department-settings.xml:company-settings.xml"/>
</propertypath>
</propgen>
</target>
You will notice that the property files in the above example are XML. We made <propgen> recognize both the traditional
java.properties format as well as our simple XML format-- XML format is convenient to parameterize
XSLT transformations. In this way, we have no duplication-- we can specify single properties
used both in Java code and in XSLT transformations. For example:
<target name="doc" depends="init">
<style
in = "content.xml"
out = "index.html"
style= "front-page.xsl">
<param
name = "properties"
expression = "temp/projecta-output-properties.xml"/>
</style>
</target>Matt
--Craeg
