The construction in question is here (slightly edited)
<copy file="${java.dir}/org/apache/avalon/excalibur/datasource/AbstractJdbcConnection.java"
tofile="${build.src}/org/apache/avalon/excalibur/datasource/AbstractJdbcConnection.java"
filtering="yes"/><javac srcdir="${java.dir}"
destdir="${build.classes}"
debug="${build.debug}"
optimize="${build.optimize}"
deprecation="${build.deprecation}"
target="1.2">
<classpath refid="project.class.path" />
<src path="${build.src}"/>
<exclude name="org/apache/avalon/excalibur/datasource/AbstractJdbcConnection.java"/>
<exclude name="org/apache/avalon/excalibur/datasource/JdbcConnection.java"/>
</javac>
The copy operation replaces some tokens to enable or disable JDBC3 compilation. Note that the Java file in question is explicitly excluded from the compilation but this has no effect as the compiler brings it in anyway to satisfy dependencies. This build relies on the <src> element being created before the "srcdir" attribute is set to ensure the compiler picks up the filtered code and not the unfiltered original.
Actually my expectation was that Ant1 would also set attributes first but the RuntimeConfigurable comes into play. Interestingly attribute setting is deferred to runtime but nested element creation is not. Hmmm. Also, for top-level tasks, it is the other way around.
Anyway, I'd appreciate some thoughts on whether there should be a defined order of attribute setting versus element creation. Should this be specified in Ant1? How about Ant2? Alternatively, should it be left undefined? In that case Build files which rely on any particular order would be considered defective even if they happened to work
Anyway, IMHO, I think this buildfile is broken.
Thoughts?
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
