Я использую муравья 1.8.0 и Java 1.6.0.17, и я сталкиваюсь со странной проблемой.
В моем build.xml у меня есть простая задача, которая компилирует код
<javac destdir="${dir.build.classes}" debug="on">
<classpath refid="classpath"/>
<src path="${dir.src.java}"/>
</javac>
В "пути к классу" банка, назовите его library.jar
В более поздней задаче я должен добавить несколько классов к library.jar
, который мне действительно нравится это
<jar destfile="library.jar" update="true" duplicate="fail">
<fileset dir="${dir.build.classes}">
<include name="some/class/files"/>
</fileset>
</jar>
Это перестанет работать с ошибкой Unable to rename old file (library.jar) to temporary file
Я всунул вызов к handle.exe прежде и после вызова javac, и я могу подтвердить, что процесс Java, рабочий муравей захватывает дескриптор файла к library.jar во время вызова javac, и он не бросает его. Это вызывает мою более позднюю попытку обновить банку для сбоя.
Почему муравей сохранил бы дескриптор к банке в пути к классу открытым даже после того, как задача javac завершена?
Итак, я нашел ответ после некоторых экспериментов. При добавлении fork = "true"
к моей javac
задаче дескриптор файла закрывается в конце задачи. Это позволяет моей модификации jar-файла быть успешной позже в сборке.
Это прискорбно, потому что я должен не забывать добавлять это к каждой восходящей задаче javac.
Проблема блокировки окон. Любой процесс/поток, считывающий файл, будет препятствовать его переименованию, что и делает задача застежка -молния при обновлении существующего файла jar.
Я предполагаю, что дескриптор файла остается открытым, потому что вы используете ссылку на путь к классам. Возможно, дескрипторы файлов будут закрыты, если будет явно задан путь к классам задачи Javac?
Кажется, это связано с конфигурацией пути к классам, и первая операция с файлом jar сохраняет его открытым. Я решил эту проблему, удалив "." из моей переменной env пути к классам.