views:

34

answers:

4

Hello everyone,

I get a very confusing reaction from my ant build-file and I'm wondering whether I'm just not clever enough or this might actually be a bug.

I've got the following property set globally in my project:

<property name="lib.dir" location="lib"/>

Then I'll try to add some files out of this directory into a jar file via fileset (more than one resource):

<fileset dir="${basedir}" includes="lib/*filename*"/>

There should be (and exist) 3 different libraries, which are matched that way. However, if I try to use the following, it doesn't work and no files are included:

<fileset dir="${basedir}" includes="${lib.dir}/*filename*"/>

Note that the only differences lies in the usage of the global property. Now the simple question: why does the first version work as advertised, but the second doesn't?

A: 

Please check the actual value of "lib.dir" just before and maybe after the task that uses the "fileset" expression. Just to make sure, that it hasn't been changed accidently after you've set it globally. The <echo/> task can help.


Maybe I got the solution. The description of the locationattribute is:

Sets the property to the absolute filename of the given file. If the value of this attribute is an absolute path, it is left unchanged (with / and \ characters converted to the current platforms conventions). Otherwise it is taken as a path relative to the project's basedir and expanded.

Simply use the value attribute instead of location. Here's a test script to show the difference:

<project name="test">

    <property name="test1" location="lib"></property>
    <property name="test2" value="lib"></property>

    <target name="target" description="description">
       <echo>${test1}</echo>
       <echo>${test2}</echo>
    </target>

</project>

The output on my system is as follows:

Buildfile: D:\Develop\workspace-jabber\scrapbook\build.xml
target:
     [echo] D:\Develop\workspace-jabber\scrapbook\lib
     [echo] lib
BUILD SUCCESSFUL
Total time: 307 milliseconds
Andreas_D
I added the following echo task just before the jar tast:<fileset dir="${basedir}" includes="${lib.dir}/*glpkjni*"/>Output was:[echo] DEBUG: Fileset includes is: [pathToDir]/lib/*glpkjni*which should suggest, that at least the property evaluation should actually work ...
Michael Schober
A: 

When creating the property (is it done global or in a target?), does the directory lib exist? If not, the location attribute does not work - use a value attribute instead or better define the property after creating the directory.

Arne Burmeister
The lib directory already exists
Michael Schober
A: 

I have found a clue to the answer, but not the whole thing yet.

I runned both versions of the fileset with ant -debug and here is what happens.

In the working, not-using-property version, I get the following output:

fileset: Setup scanner in dir [pathToDir] with patternSet{ includes: [lib/*filename*] excludes: [] }

whereas in the should-be-working-but-doesn't version I get:

fileset: Setup scanner in dir [pathToDir] with patternSet{ includes: [ [pathToDir]/lib/*filename*] excludes: [] }

As you can see, ant add's the [pathToDir] in the regexp, thus searching for

[pathToDir]/[pathToDir]/lib/*filename*

which obviously doesn't exist. Problem now: how do I have to modify my version to have it working properly?

Michael Schober
A: 

As indicated above, the problem was that ${lib.dir} too contained the whole path, thus searching for [pathToDir]/[pathToDir]/lib/filename.

To clip away the unwanted [pathToDir] in the ${lib.dir} property, I now used the task. I got now the following, but imho not so nice looking solution:

<basename property="lib.dir.rel" file="${lib.dir}"/>
<fileset dir="${basedir}" includes="${lib.dir.rel}/*filename*"/>

P.S.: On a second look, I found that Andreas_D also found the right reason and a good suggestion yesterday, which I must have overlooked :-/

Michael Schober