Рекомендации по компоновке проекта Java для сборок на основе Ant

Я немного шокирован тем, что (если?) Этот точный вопрос не был задан, но 15 минут сканирования ТАК не выявили точного совпадения. (Если я ошибаюсь, укажите мне правильный путь и проголосуйте за закрытие ...)

Вопрос 1:

Каковы наилучшие методы размещения проектов Java в системе сборки Ant? Для наших целей у нас есть следующий контекст (возможно, большая часть которого не имеет значения):

• Большинство разработчиков используют Eclipse (не все)
• Проект поддерживается в подрывной версии
• Сборки проектов недавно были перенесены в Hudson, в котором мы хотим использовать плагин выпуска для управления выпусками, а также некоторые настраиваемые сценарии для обработки автоматического развертывания.
• Этот проект представляет собой «обычное» приложение, своего рода «производственный прототип» с очень ограниченным кругом пользователей, но они находятся на удаленных объектах с разделением воздушных зазоров, поэтому доставляются отслеживаемые по версиям артефакты для легкой установки, ручного сбора / восстановления данных, и удаленная диагностика важна.
• Некоторые зависимости (JAR) включены в репозиторий SVN; другие могут быть получены с помощью сценария ant во время сборки, если это необходимо. Ничего особенного, вроде Айви, пока нет (и, пожалуйста, не говорите мне переходить на Maven3 ... Я знаю, и мы сделаем это, если / когда придет подходящее время).
• Сборка включает в себя JUnit, FindBugs, CheckStyle, PMD, JavaDoc, немного настраиваемой генерации документации
• Два или три основных артефакта JAR (основной артефакт приложения плюс пара минимальных API JAR для включения в несколько связанных приложений)
• Desire to distribute the following distribution artifacts:
  • a "Full" source+bin tarball with all dependencies resolved, jars and JavaDoc prebuilt
  • tar-архив bin, содержащий только документы и JavaDoc, jar-файлы, вспомогательные сценарии-оболочки и т. д.
  • «Партнерский» источник + корзина, в которой есть «общий» источник, на который, вероятно, будут смотреть партнерские разработчики, и связанные тестовые наборы.

Текущая структура выглядит так

project-root/
project-root/source                 
project-root/source/java             // main application (depends on -icd)
project-root/source/java-icd         // distributable interface code
project-root/source/test             // JUnit test sources
project-root/etc                     // config/data stuff
project-root/doc                     // pre-formatted docs (release notes, howtos, etc)
project-root/lib                     // where SVN-managed or Ant-retrieved Jars go
project-root/bin                     // scripts, etc...

Во время сборки он расширяется и включает:

build/classes                        // Compiled classes
build/classes-icd 
build/classes-test
build/javadoc
build/javadoc-icd                    
build/lib                            // Compiled JAR artifacts
build/reports                        // PMD, FindBugs, JUnit, etc... output goes here
build/dist                           // tarballs, zipfiles, doc.jar/src.jar type things, etc..
build/java                           // Autogenerated .java products
build/build.properties               // build and release numbering, etc...

Вопрос 2:

Как мне сохранить строгое разделение в дереве разработки между элементами, контролируемыми версиями, и артефактами времени сборки WHILE, создавая согласованное распределение, как указано выше, И, что позволяет мне обрабатывать дерево разработки как операционное / распределение во время разработки и тестирования? В частности, мне не нравится, когда моя задача <jar> удаляет файлы .jar в lib каталог верхнего уровня - этот каталог в деревьях разработчиков является неприкосновенным Территория СВН. Но распространение чего-то для публичного использования с build/lib/*.jar сбивает с толку. То же самое верно в отношении документации и других встроенных артефактов, которые мы хотим разместить в едином месте в дистрибутиве, но не хотим, чтобы разработчики и пользователи использовали совершенно разные структуры каталогов.

Размещение всех сгенерированных продуктов в отдельном build/ каталоге очень удобно для разработки, но это неприятный артефакт для распространения. В целях распространения я бы предпочел, чтобы все JAR-файлы находились в одном lib месте, на самом деле, структура, подобная приведенной ниже, имеет наибольший смысл. В настоящее время мы создаем эту структуру "на лету" с ant dist, выполняя некоторые сложные манипуляции с путями при создании артефактов .tar.gz и .zip.

Как я думаю, должно выглядеть расстояние:

project-root/
project-root/source                  // present in only some dists 
project-root/etc                     // same as in development tree
project-root/doc                     // same as in development tree
project-root/doc/javadoc             // from build 
project-root/lib                     // all dependency and built JAR files
project-root/bin                     // same as in development tree
build.properties               // build and release numbering, etc...

Этот вопрос узко связан с тем, «как поддерживать чистую структуру проектов разработки и распространения?» как я просил выше; но также для сбора информации о макетах проектов Java / Ant в целом и критики нашего конкретного подхода. (Да, если вы считаете, что это должна быть вики сообщества, я сделаю так ...)