Совет относительно хорошего инструмента сборки Java, хорошо интегрированного с затмением
Я работаю в малочисленной команде (3 человека) на нескольких модулях (приблизительно 10 в настоящее время). Компиляция, интеграция и управление версиями сборки становятся все более утомительными. Я ищу хорошую сборку / инструмент интеграции для замены / завершает Муравья.
Вот описание нашей текущей среды разработки: - несколько модулей в зависимости от каждого и на сторонних БАНКАХ - Некоторые могут экспортировать БАНКИ, некоторые ВОЙНЫ экспорта, некоторые автономные, выполнимые БАНКИ экспорта (с Толстой Банкой) - Javadoc для всех них - Мы работаем с затмением - Пользовательский скрипт Ant для каждого модуля. Многие избыточная информация между конфигурацией затмения и скриптами Ant. Например, для автономного толстого JAR, мы перечислили все рекурсивные зависимости, тогда как идеально, он мог ясно быть импортирован из конфигурации затмения. - Исходный код является имеющим версию с помощью SVN
Вот то, что я хотел бы, чтобы идеальный инструмент интеграции сделал для меня:
Автоматизируйте выпуски и управление версиями модулей. Идеально, инструмент интеграции должен обнаружить, если новая версия необходима. Например, если я хочу выпустить проект A, который зависит от проекта B, и если я внес небольшие изменения на проекте B локально, затем инструмент интеграции должен сначала выпустить новую версию B также и сделать на основе его.
Интегрируйтесь сильно с затмением, так, чтобы это могло получить зависимости между модулями, и третье лицо освобождает из его конфигурации. BTW, я хотел бы продолжить настраивать путь сборки с затмением, не обновляя некоторый другой материал ".xml". Я видел, что Gradle может генерировать файлы проекта затмения из своей конфигурации, но дубликат был бы большим.
Включите "живую" и прозрачную разработку на локальных проектах. Я подразумеваю, что часто вношу небольшие изменения на ядре / общие проекты при разработке основного / "листовые" проекты. Я хотел бы иметь свои изменения на базовых проектах, сразу доступных листовым проектам без потребности публикации (даже локально) БАНКИ моих базовых проектов.
Сохраните все версии выпусков моего модуля на внешнем сервере. Самое простое (папка долей / Webdav) было бы лучшим. Хорошая веб-страница со списком модулей и поставленных артефактов была бы большой также.
Я навел справки о многих вещах. От Ant4eclipse (для интеграции конфигурации Eclipse в мой скрипт Ant), к инструментам Maven / Ivy / Gradle.
Я немного смущен. Вот то, что я понял до сих пор: - знаток является великим / крупный инструмент, но несколько тверд и обязывает Вас изгибаться к его структуре и понятиям. Это основано на описании, а не на сценариях. При выходе из пути необходимо разработать Вас собственные плагины. - Плющ менее мощен, чем знаток, он обрабатывает меньше материала, но более гибок. - Gradle является промежуточным. Это - общая цель. Это позволяет писать сценарий, а также "конвенция основывала" конфигурацию. Это интегрирует Муравья и расширяет его.
Таким образом в этой точке я ищу фактические свидетельства от реальных пользователей. Какие инструменты Вы используете? Как? У Вас есть те же потребности как я? Это упрощает Вашу жизнь или входит в путь?
Существует ли образец некоторые варианты использования или рабочая область skeletons там, что я мог использовать в качестве начальной точки для наблюдения то, к чему эти инструменты способны?
Извините за длину этого сообщения. И заранее спасибо за Вас совет.
С уважением,
Raphael
6 ответов
Автоматизируйте выпуски и управление версиями модулей (...)
Концепции управления версиями и репозиторием встроены в Maven, и они могут здесь поместиться.
Maven поддерживает зависимости SNAPSHOT . При использовании моментального снимка Maven будет периодически пытаться загрузить последний доступный моментальный снимок из репозитория при запуске сборки. SNAPSHOT обычно используются, когда проект находится в активной разработке.
Maven 2 также поддерживает диапазоны версий (я не особо рекомендую их, но это уже другая история), которые позволяют, например, настроить A в зависимости от версии [4.0,) of 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 есть некоторая кривая обучения.
Инструменты CI? На мой взгляд, есть только один: Hudson CI.
Однажды я создал среду разработки программного обеспечения для Java из следующих компонентов:
- eclipse IDE
- mercurial
- bugzilla
- maven
- Nexus
- Hudson CI
и немного apache, mysql, php, perl, python, ... для интеграции.
Hudson не был интегрирован с eclipse, и это было сделано специально, потому что я хотел собирать на отдельном сервере. Для всех остальных инструментов у меня была идеальная кросс-интеграция (например: mylyn на eclipse для общения с bugzilla, m2eclipse для использования maven eclipse, множество плагинов для hudson, ...)
.Мы начали интегрировать Gradle в наш процесс сборки, и я могу добавить к уже опубликованным ответам, что Gradle также будет работать. Ваши предположения в основном верны, gradle более нестандартный, но мощный и позволяет создавать сценарии и тому подобное в самой сборке. Кажется, что большинство вещей, которые может делать maven, делает и gradle.
Теперь о ваших индивидуальных моментах:
Управление версиями : gradle поддерживает карты зависимостей, управление версиями, и если вы добавляете сервер CI, вы можете запускать автоматические / зависимые сборки. Например, почти все наши «результаты» - это .wars, но у нас есть несколько библиотек кода (.jars) и один исполняемый файл .jar в разработке. Одна конфигурация состоит в том, чтобы сделать войны и «толстую банку» зависимыми от общих библиотек кода.Затем, когда общие библиотеки обновлены, увеличьте версии в общих библиотеках, протестируйте потребляющие проекты, а затем используйте способность Хадсона запускать зависимые проекты для их повторного развертывания. Есть и другие способы, но на данный момент они, кажется, работают для нас лучше всего.
Полная интеграция с eclipse : Вы правы, gradle может генерировать файлы eclipse. Мы склонны использовать задачу eclipseCp (для обновления .classpath) только после того, как приступим к работе, поскольку нужно изменить только путь к классам. Это довольно странно (берет вашу JRE по умолчанию, поэтому убедитесь, что она правильная, не добавляет exported = "true", если вам это нужно), но дает вам 99% пути туда.
Обеспечьте «живую» и прозрачную разработку локальных проектов : я не уверен в этом. Я только взломал gradle в этом случае; удалив артефакт в проекте-потребителе и пометив общий проект как таковой в eclipse, а затем вернувшись назад.
Хранить все версии выпусков моего модуля на внешнем сервере : поддерживаются простые и многие подходы, аналогичные Maven.
Что касается примеров, хороши документы для Gradle, а также примеры проектов, которые поставляются с полным zip-файлом. Они довольно быстро заставят вас начать работу.
Взгляните на Муравей Айви. http://ant.apache.org/ivy/
Серебряных пуль не бывает, но по моему опыту Maven - отличный инструмент управления проектами. Лично мне нравится использовать комбинацию subversion (для контроля версий), maven (для управления проектами/сборками) и hudson (для непрерывной сборки/интеграции).
Я считаю, что конвенция, привнесенная maven, очень полезна для переключения контекста и отлично подходит для управления зависимостями. Может быть неприятно, если банки отсутствуют в репозиториях, но вы можете установить их локально, а когда будете готовы, вы можете разместить свой собственный частный репозиторий, который будет зеркалировать другие места. У меня был хороший опыт использования sonar.nexus от http://www.sonatype.com/ . Они также предоставляют отличную бесплатную книгу для начала работы.
Сейчас это может показаться излишеством, но создание хорошей среды сборки / тестирования / интеграции / выпуска сейчас, принесет дивиденды позже. Ее всегда сложнее модернизировать, и это то, что вы можете легко воспроизвести.
Наконец, я предпочитаю интеграцию Netbeans с maven, но это только мое мнение :)
.Некоторые из ваших тем являются частью управления развертыванием и выпуском.
Вы можете попробовать такой продукт, как: Xebia DeployIt
(с персональной версией , которая бесплатна)