Я немного шокирован тем, что (если?) Эти точные вопросы не задавались, но 15 минут сканирования ТАК не дали точного соответствия.(Если я ошибаюсь, укажите мне правильный путь и проголосуйте за закрытие ...)
Вопрос 1:
Каковы лучшие практики для размещения проектов Java подСистема сборки Ant? Для наших целей у нас есть следующий контекст (возможно, большая часть которого не имеет значения):
- Большинство разработчиков используют Eclipse (не все)
- Projectподдерживается в subversion
- Сборки проектов недавно были перенесены в Hudson, в котором мы хотим использовать плагин релиза для управления релизами и некоторые пользовательские скрипты для управления автоматическим развертыванием
- Этот проект "обычное «приложение», своего рода «производственный прототип» с очень ограниченным пулом пользователей, но они находятся на удаленных площадках с разделением воздушной прослойки, поэтому важно предоставлять проверенные версии отслеживаемые артефакты для простой установки, ручного сбора / восстановления данных и удаленной диагностики.
- Некоторые зависимости (JAR) включены в репозиторий SVN;другие могут быть получены с помощью скрипта ant во время сборки, если это необходимо.Ничего такого, как Айви, пока нет (и, пожалуйста, не говорите мне, чтобы я переключился на Maven3 ... Я знаю, и мы сделаем это, если / когда придет подходящее время.)
- Сборка включает JUnit, FindBugs,CheckStyle, PMD, JavaDoc, немного пользовательской генерации документации
- Два или три основных артефакта JAR (артефакт основного приложения плюс пара минимальных JAR API для включения в несколько связанных приложений)
- Желание распространять следующие артефакты распространения:
- a "Полный" архив исходного кода + bin со всеми разрешенными зависимостями, jars и предварительно созданный JavaDoc
- tar-файл bin, только с документами и JavaDoc, jars,и вспомогательные сценарии обертки и т. д.
- источник "Partner" + корзина, в которой есть "общий" источник, на который могут рассчитывать разработчики-партнеры, и связанные тестовые случаи
Текущая структура выглядит следующим образом
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:
Как я могуmaintain строгое разделение в дереве разработки между элементами, контролируемыми ревизиями, и артефактами времени сборки WHILE , создающими согласованное распределение, как указано выше И , что позволяет мне рассматривать дерево разработки как операционное / распределение во времяразработка и тестирование? В частности, мне не хочется, чтобы мои <jar> задачи сбрасывали файлы .jar в каталог верхнего уровня lib - этот каталог в деревьях разработчиков является неприкосновенной территорией SVN.Но распространение чего-либо для публичного использования с build/lib/*.jar вызывает недоумение.То же самое относится и к документации и другим встроенным артефактам, которые мы хотим отображать в согласованном месте в дистрибутиве, но не хотим, чтобы разработчики и пользователи использовали совершенно разные структуры каталогов.
Наличие всех сгенерированных продуктовв отдельном каталоге build/ очень хорошо для времени разработки, но это раздражающий артефакт для распространения.В целях распространения я бы предпочел, чтобы все JAR-файлы находились в одном lib месте, на самом деле, структура, подобная приведенной ниже, имеет наибольшее значение.В настоящее время мы строим эту структуру на лету с помощью ant dist, выполняя некоторые сложные операции с путями при построении артефактов .tar.gz и .zip.
То, что я думаю, должно выглядеть как dist:
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 в целом и критике нашего конкретного подхода.(Да, если вы считаете, что это должна быть Вики сообщества, я сделаю это так ...)