You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by da...@ac.com on 2000/08/07 23:41:46 UTC

Conditional Filter Problem

I'm having problems setting up a filter that is conditional to the target
development environment.  I have an architecture built on Java 2
collections, but some of my users use a Java 1.1.8 environment.  There is
an issue that in Java 2, the collections library is located in the
"java.util" package, while for Java 1.1 developers must include a
collections.jar file and the corresponding classes belong to the
"com.sun.java.util.collections" package.  I'd like to simplify their build
process by automatically setting the class imports.  My approach to
accomplish this is to change the imports in the Java code to use a filter.
So import an Iterator is done by:

  import @collections.package@.Iterator;

In my build.xml script I attempt to set the collections.package filter to
be "java.util" for a Java 2 environment or "com.sun.java.util.collections"
for a Java 1.1 environment.  My script contains conditional targets based
on a build for Java 1.1 property.  If the users want to build for Java 1.1,
then they uncomment a property declaration in the init target (see
build.xml extract below).

This does not work, however since it appears the filter tasks are always
executed even if they are contained in a target that is not executed.  In
fact, it appears that which version of the filter is used is based solely
on which filter is set last.  Is this a bug in Ant, or is there a better
way to accomplish setting a filter to a dependent value?

Thanks, ~dmr

build.xml extract:

  <target name="init">
    <!--
      == This property dictates the environment GRNDS will be compiled for.  If
      == it is left undefined, then GRNDS will be built for Java 2.  If it is
      == defined then, GRNDS will be built for Java 1.1.
      == uncomment this property only if you are working in a Java 1.1
      == environment, such as IBM WebSphere
      -->
    <!--property name="build-java-1.1" value="true"/-->
  </target>

  <target name="prepare-java1_1" depends="prepare" if="build-java-1.1">
    <echo message="building for Java 1.1.8 platform"/>
    <echo message="collections.package set to com.sun.java.util.collections"/>
    <filter token="collections.package" value="com.sun.java.util.collections"/>
  </target>

  <target name="prepare-java2" depends="prepare" unless="build-java-1.1">
    <echo message="building for Java 2 platform"/>
    <echo message="collections.package set to java.util"/>
    <filter token="collections.package" value="java.util"/>
  </target>

  <target name="prepare" depends="init">
    <mkdir dir="${build.dir}"/>
  </target>

  <target name="prepare-src" depends="prepare,prepare-java2,prepare-java1_1">
    <!-- create directories -->
    <mkdir dir="${build.src}"/>
    <mkdir dir="${build.dest}"/>

    <!-- copy src files -->
    <copydir src="${src.dir}"
             dest="${build.src}"
             filtering="on"
             excludes="**/*.~*"/>
  </target>


Re: Conditional Filter Problem

Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "dmr" == damon m rolfs <da...@ac.com> writes:

 dmr> This does not work, however since it appears the filter tasks
 dmr> are always executed even if they are contained in a target that
 dmr> is not executed.  In fact, it appears that which version of the
 dmr> filter is used is based solely on which filter is set last.

Your diagnose is correct. This is the way it is currently implemented
(and has always been as far as I can tell).

The handling of <property> (the same behavior you see for <filter>,
only difference is that you can put <property> tags outside of
<target>s) is bound to change in the future - expect <filter> to
change at the same time.

Stefan