Советы по хорошему инструменту сборки Java, хорошо интегрированному с eclipse - PullRequest
6 голосов
/ 06 июля 2010

Я работаю в небольшой команде (3 человека) над несколькими модулями (около 10 в настоящее время). Компиляция, интеграция и управление версиями сборки становится все более и более утомительным. Я ищу хороший инструмент для сборки / интеграции для замены / завершения Ant.

Вот описание нашей текущей среды разработки: - Несколько модулей в зависимости от каждого JAR-файла стороннего производителя. - Некоторые могут экспортировать JARS, некоторые экспортировать WARS, некоторые экспортировать автономные, работающие JARS (с Fat-Jar) - Javadoc для всех них - работаем с затмением - Пользовательский скрипт Ant для каждого модуля. Много избыточной информации между конфигурацией eclipse и сценариями Ant. Например, для автономного Fat-JAR мы перечислили все рекурсивные зависимости, тогда как в идеале он может быть явно импортирован из конфигурации eclipse. - Исходный код версии с использованием SVN

Вот что я хотел бы, чтобы идеальный инструмент интеграции сделал для меня:

  • Автоматизация выпусков и версий модулей. В идеале инструмент интеграции должен определять, нужна ли новая версия. Например, если я хочу выпустить проект A, который зависит от проекта B, и если я внес небольшие изменения в проект B локально, то инструмент интеграции должен сначала выпустить новую версию B и сделать A на основе это.

  • Сильная интеграция с eclipse, чтобы он мог получить зависимости между модулями и сторонними библиотеками из своей конфигурации. Кстати, я хотел бы продолжить настройку пути сборки с помощью eclipse, не обновляя другие ".xml" вещи. Я видел, что Gradle может генерировать файлы проекта Eclipse из своей конфигурации, но его коллега был бы великолепен.

  • Включение "живой" и прозрачной разработки для локальных проектов. Я имею в виду, что я часто делаю небольшие изменения в основных / общих проектах при разработке основных / «листовых» проектов. Я хотел бы, чтобы мои изменения в основных проектах были немедленно доступны для конечных проектов без необходимости публикации (даже локально) JAR-файлов моих основных проектов.

  • Храните все версии выпусков моего модуля на внешнем сервере. Самый простой (папка общего доступа / Webdav) будет лучшим. Неплохая веб-страница со списком модулей и доставленных артефактов.

Я искал много вещей. От Ant4eclipse (для интеграции конфигурации Eclipse в мой скрипт Ant) до инструментов Maven / Ivy / Gradle.

Я немного растерялся. Вот что я понял до сих пор: - Maven - отличный / большой инструмент, но он довольно жесткий и обязывает вас склоняться к его структуре и концепциям. Он основан на описании, а не на сценариях. Если вы выходите из этого пути, вы должны разработать свои собственные плагины. - Плющ менее мощный, чем Maven, он обрабатывает меньше вещей, но более гибок. - Gradle находится между ними. Это общее назначение. Это позволяет создавать сценарии, а также настраивать «на основе соглашения». Он интегрирует Ant и расширяет его.

Так что на данный момент я ищу реальные отзывы реальных пользователей. Какие инструменты вы используете? Как ? У вас есть те же потребности, что и у меня? Это облегчает вашу жизнь или мешает?

Есть ли примеры некоторых вариантов использования или скелетов рабочего пространства, которые я мог бы использовать в качестве отправной точки, чтобы увидеть, на что способны эти инструменты?

Извините за длину этого сообщения. И заранее спасибо за совет.

С уважением,

Raphael

Ответы [ 6 ]

2 голосов
/ 06 июля 2010

Мы начинаем интегрировать Gradle в наш процесс сборки, и я могу добавить к опубликованным ответам, что Gradle также будет работать.Ваши предположения в основном верны, gradle больше не подходит, но мощен и позволяет создавать сценарии и тому подобное в самой сборке.Кажется, что большинство вещей, которые может сделать maven, Gradle делает также.

Теперь для ваших индивидуальных точек:

Управление версиями : Gradle поддерживает карты зависимостей, управление версиями, и если выдобавив сервер CI, вы можете запускать автоматические / зависимые сборки.Например, почти все наши «результаты» являются .wars, но у нас есть несколько библиотек кода (.jars) и один исполняемый файл .jar в разработке.Одна из конфигураций - сделать войны и «толстяк» зависимыми от библиотек общего кода.Затем, когда общие библиотеки обновляются, повышают версии на общих библиотеках, тестируют проекты-потребители, а затем используют способность Хадсона запускать зависимые проекты для их повторного развертывания.Есть и другие способы, но сейчас, похоже, они лучше всего работают для нас.

Сильная интеграция с eclipse : вы правы, gradle может генерировать файлы eclipse.Мы склонны использовать задачу eclipseCp (для обновления .classpath) только после начала работы, поскольку изменились только потребности classpath.Это немного странно (захватывает вашу JRE по умолчанию, поэтому убедитесь, что она правильная, не добавляет exported = "true", если вам это нужно), но дает вам 99% пути.

Включить «живую» и прозрачную разработку для локальных проектов : В этом я не уверен.В этом случае я взломал только gradle;удалив артефакт в проекте-потребителе и пометив общий проект как таковой в Eclipse, а затем вернул его обратно.

Храните все версии выпусков моего модуля на внешнем сервере : просто иПоддерживаются многие подходы, аналогичные Maven.

Что касается примеров, то документы для gradle хороши, как и примеры проектов, которые поставляются с полным zip.Они помогут вам быстро заработать.

2 голосов
/ 06 июля 2010

Автоматизация выпусков и управления версиями модулей (...)

Концепции управления версиями и репозитория встроены в Maven и могут здесь подходить.

Maven поддерживает SNAPSHOT-зависимостей .При использовании моментального снимка Maven будет периодически пытаться загрузить последний доступный моментальный снимок из репозитория при запуске сборки.SNAPSHOT обычно используются, когда проект находится в активной разработке.

Maven 2 также поддерживает диапазоны версий (я не очень рекомендую их, но это другая история), которые позволяют, например, настроить A длязависит от версии [4.0,) из B (любая версия больше или равна 4.0).Если вы создадите и выпустите новую версию B, A будет использовать ее.

Сильная интеграция с Eclipse

Плагин m2eclipse обеспечивает двунаправленную синхронизацию с Eclipse.

Включить«живая» и прозрачная разработка для локальных проектов.

Плагин m2eclipse поддерживает «разрешение рабочей области»: если проект A зависит от проекта B и если проект B находится в рабочей области, вы можете настроить A так, чтобы он зависелна источниках B, а не на B.jar (это режим по умолчанию, если я не ошибаюсь).Таким образом, изменения в источниках B будут видны напрямую, без необходимости сборки B.jar.

Храните все версии выпусков моего модуля на внешнем сервере.

Как упоминалось ранее, на самом деле это центральная концепция Maven (у вас даже нет выбора), и поддерживаются развертывание через file: // или dav: //.


Подводя итог, Maven (возможно) не единственный кандидат, но я уверен, что он подойдет:

  • Ваш проект не настолько экзотичен или сложен, в нем нет ничегоотпугивая от вашего описания (вероятно, потребуется некоторый рефакторинг структуры, но это не должно иметь большого значения).
  • Maven также предоставляет рабочий процесс, основанный на лучших практиках.
  • m2eclipse обеспечивает сильныйинтеграция с IDE.

Но у Maven есть некоторая кривая обучения.

2 голосов
/ 06 июля 2010

CI инструменты?Для меня есть только один: Хадсон CI .


Я однажды установил среду разработки программного обеспечения для Java с компонентами:

  • Eclipse IDE
  • mercurial
  • bugzilla
  • maven
  • Nexus
  • Hudson CI

и некоторые apache, mysql, php, perl, python, .. для интеграции.

Hudson не был интегрирован с Eclipse, и это было сделано специально, потому что я хотел построить на отдельном сервере.для всех остальных инструментов у меня была идеальная перекрестная интеграция (например: mylyn on eclipse для общения с bugzilla, m2eclipse для использования maven eclipse, множество плагинов для hudson, ...)

1 голос
/ 06 июля 2010

Серебряных пуль нет, но по моему опыту, Maven - отличный инструмент управления проектами.Лично мне нравится использовать комбинацию subversion (для контроля версий), maven (для управления проектами / сборками) и hudson (для непрерывной сборки / интеграции).

Я считаю, что соглашение, принесенное maven, действительно полезнодля переключения контекста и отлично подходит для управления зависимостями.Может быть неприятно, если в репозиториях нет jar-файлов, но вы можете установить их локально, а когда вы будете готовы, вы можете разместить свой собственный частный репозиторий, который отражает другие места.У меня был хороший опыт использования sonar.nexus http://www.sonatype.com/.Они также предоставляют превосходную бесплатную книгу для начала работы.

Может показаться, что это излишне, но настройка хорошей среды сборки / тестирования / интеграции / выпуска сейчас окупит дивиденды позже.Его всегда сложнее адаптировать ретро, ​​и это то, что вы можете легко воспроизвести.

Наконец, я предпочитаю интеграцию Netbeans для maven, но это только я:)

1 голос
/ 06 июля 2010

Посмотрите на Ant Ivy. http://ant.apache.org/ivy/

0 голосов
/ 06 июля 2010

Некоторые из ваших тем являются частью управления развертыванием и выпуском.

Вы можете проверить продукт как: Xebia DeployIt
персональным изданием , которое бесплатно)

...