Is 'copyfiles' a standard ant task?

Question

I have a NetBeans project that I'm trying to compile manually from command-line ant. When running on the same machine that has NetBeans installed, it works flawlessly.

However, if I run ant on a central continuous integration server (no NetBeans installed) it fails on a <copyfiles> task:

BUILD FAILED
/var/lib/jenkins/workspace/project_name/nbproject/build-impl.xml:697: Problem: failed to create task or type copyfiles
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any <presetdef>/<macrodef> declarations have taken place.

The target is in the auto-generated build-impl.xml, which looks something like this:

<target depends="init" name="library-inclusion-in-archive" unless="dist.ear.dir">
    <copyfiles files="${file.reference.some_dependency.jar}" todir="${build.web.dir}/WEB-INF/lib"/>
</target>

When I look at the ant manual, copyfiles isn't even a proper ant task. So what's up?

How can I get this to run on a machine with no NetBeans installation?

Answer 1

Per this advice, I verified the dependencies, and indeed the lib/CopyLibs directory was not versioned in our source control repo. That's why my local environment was able to compile, but the CI server wasn't.

After adding the dependency to the classpath - org-netbeans-modules-java-j2seproject-copylibstask.jar specifically - the ant build succeeded.

On a personal note, I find it absurd that NetBeans needs an external dependency for a task that - trivially - exists as a standard ant task.

Answer 2

From the Ant Copy man page:

"Important Encoding Note: The reason that binary files when filtered get corrupted is that filtering involves reading in the file using a Reader class. This has an encoding specifying how files are encoded. There are a number of different types of encoding - UTF-8, UTF-16, Cp1252, ISO-8859-1, US-ASCII and (lots) others. On Windows the default character encoding is Cp1252, on Unix it is usually UTF-8. For both of these encoding there are illegal byte sequences (more in UTF-8 than for Cp1252).

How the Reader class deals with these illegal sequences is up to the implementation of the character decoder. The current Sun Java implementation is to map them to legal characters. Previous Sun Java (1.3 and lower) threw a MalformedInputException. IBM Java 1.4 also throws this exception. It is the mapping of the characters that cause the corruption.

On Unix, where the default is normally UTF-8, this is a big problem, as it is easy to edit a file to contain non US Ascii characters from ISO-8859-1, for example the Danish oe character. When this is copied (with filtering) by Ant, the character get converted to a question mark (or some such thing).

There is not much that Ant can do. It cannot figure out which files are binary - a UTF-8 version of Korean will have lots of bytes with the top bit set. It is not informed about illegal character sequences by current Sun Java implementions."

So it looks like NetBeans copyfiles task was created to avoid that unfixable bug when copying Jar files. Not as absurd as it sounds.