Является ли copyfiles стандартной муравьиной задачей?

Question

У меня есть проект NetBeans, который я пытаюсь скомпилировать вручную из командной строки ant. При работе на той же машине, на которой установлен NetBeans, он работает безупречно.

Однако, если я запускаю ant на центральном сервере непрерывной интеграции (NetBeans не установлен), он завершается ошибкой для задачи <copyfiles>:

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.

Цель находится в автоматически сгенерированном build-impl.xml, который выглядит примерно так:

<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>

Когда я смотрю на руководство по муравьям , copyfiles даже не является правильной задачей муравья. Так что случилось?

Как заставить его работать на компьютере без установки NetBeans?

Answer 1

За этот совет , я проверил зависимости, и действительно, каталог lib/CopyLibs был не версионным в нашем репозитории с контролем версий. Вот почему моя локальная среда могла компилироваться, а CI-сервер - нет.

После добавления зависимости в classpath - org-netbeans-modules-java-j2seproject-copylibstask.jar, в частности - сборка муравья завершилась успешно.

Что касается меня, я считаю абсурдным, что NetBeans нужна внешняя зависимость для задачи, которая - тривиально - существует как стандартная ant задача.

Answer 2

Из справочной страницы Ant Copy:

"Важное примечание о кодировке. Причиной того, что двоичные файлы при фильтрации повреждаются, является то, что фильтрация включает в себя чтение в файле с использованием класса Reader. Это имеет кодировку, определяющую, как файлы кодируются. Существует несколько различных типов кодирования: UTF-8, UTF-16, Cp1252, ISO-8859-1, US-ASCII и (много) др. В Windows кодировкой символов по умолчанию является Cp1252, в Unix это обычно UTF-8. Для обеих этих кодировок есть недопустимые последовательности байтов (больше в UTF-8, чем для Cp1252).

Как класс Reader работает с этими недопустимыми последовательностями, зависит от реализации декодера символов. Текущая реализация Sun Java предназначена для отображения их на допустимые символы. Предыдущая версия Sun Java (1.3 и ниже) вызвала исключение MalformedInputException. IBM Java 1.4 также выдает это исключение. Именно отображение символов вызывает искажение.

В Unix, где по умолчанию обычно используется кодировка UTF-8, это большая проблема, так как легко отредактировать файл, содержащий символы, отличные от US Ascii из ISO-8859-1, например, датский символ oe. Когда это копируется (с фильтрацией) Ant, персонаж конвертируется в знак вопроса (или что-то подобное).

Муравей мало что может сделать. Он не может определить, какие файлы являются двоичными - в корейской версии UTF-8 будет много байтов с установленным старшим битом. Текущие реализации Sun Java не сообщают о недопустимых последовательностях символов. "

Похоже, что задача копирования файлов NetBeans была создана, чтобы избежать этой неустранимой ошибки при копировании файлов Jar. Не так абсурдно, как кажется.