ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craeg K. Strong" <cstr...@arielpartners.com>
Subject Re: TASK SUBMISSION: jspc and projectdependencies
Date Fri, 14 Sep 2001 05:07:11 GMT
>
>
>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?
>
Agreed.  I was not the proposer of taskdefs.org-- it was John Casey-- 
John can you
give us an idea of the status of this?

>Your 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...
>
Excellent ideas.  I am afraid our current implementation is rather 
primitive.  You simply
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


Mime
View raw message