Хотите верьте, хотите нет, но ваш "утомительный" подход, вероятно, самый простой, чистый и наименее трудоемкий.
Перед тем, как прыгнуть на подножку Maven, вы должны подумать о том, что на самом деле не так, делать то, что вы делаете в настоящее время. Вы упомянули, что это утомительно и что у вас есть много файлов с файлами jar. Я создал процесс сборки для большого многомодульного проекта с использованием Maven, а затем потратил следующие 18 месяцев на его постоянную борьбу. Поверьте мне, это было утомительно, и вокруг было много файлов с банками.
После возвращения в Ant и передачи jar-файлов в систему управления версиями вместе с проектами, которые их используют, процесс проходил гораздо плавнее.
Я храню кучу файлов JAR в одном каталоге на моем компьютере, а затем, когда я создаю новый проект или мне нужно добавить новый JAR в существующий проект, это займет всего около 30 секунд:
- Скопируйте банку из JAR_REPO в проект lib dir.
- Добавить jar в build.properties
- Добавить jar в classpath в build.xml
- Добавить jar для построения пути в Eclipse.
В течение проекта эти 30 секунд несущественны, но это означает, что у меня есть проект, который можно вывести из-под контроля исходного кода и который просто работает, не требуя никакой пользовательской конфигурации Eclipse, установок Maven или пользовательских настроек.
Этот подход сэкономил мне и моей команде проекта огромное количество времени, главным образом потому, что он прост, надежен и легок для понимания.
Обновление : уточнение вызвано комментариями
@ Роберт Мунтяну: Спасибо за отзывы и обновленные комментарии. Это может показаться немного спорным, но я боюсь, что не могу согласиться с вами, что Maven проще и понятнее или что это сэкономит вам время в долгосрочной перспективе.
Из вашего сообщения:
«Я твердо верю, что декларировать зависимости проще и яснее, чем включать их вручную. С этим связана небольшая единовременная стоимость - меньшая для Ivy, чем для Maven, - но в конечном итоге она окупается».
Возможно, Maven может загрузить файл JAR для вас, а не загружать его самостоятельно, но это единственное преимущество. В противном случае Maven не проще, не понятнее, и его сложности и ограничения обойдутся вам в долгосрочной перспективе.
Ясность
Два объявления зависимостей ниже делают то же самое. Я нахожу Муравья намного яснее, чем Мавен.
Муравей Стиль:
<path id="compile.classpath">
<pathelement location="${log4j.jar}" />
<pathelement location="${spring.jar}" />
</path>
Maven Style:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>${log4j.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>${spring.version}</version>
<scope>compile</scope>
</dependency>
Простота
В версии Ant вы можете навести курсор на свойство $ {log4j.jar}, и оно покажет вам абсолютный путь к файлу jar. Вы можете искать использование compile.classpath. Вам не нужно знать намного больше.
Нет сомнений, что Maven более сложен, чем подход, который я предлагаю. Когда вы начинаете с Maven, это лишь некоторые из вопросов, на которые нужно ответить.
- Что означает groupId?
- Что означает artifactId?
- Откуда берется банка?
- Где сейчас банка?
- Что предусмотрено сфера? Кто это обеспечивает?
- Как этот файл JAR оказался в моем файле WAR?
- Почему у этой зависимости нет элемента версии?
- Я не понимаю это сообщение об ошибке. Что на земле это значит?
- Откуда этот файл с банкой? Я не заявлял об этом.
- Почему у меня есть 2 версии одного и того же файла JAR на моем classpath?
- Почему проект больше не строится? Ничего не изменилось с тех пор, как я в последний раз его построил.
- Как добавить сторонний jar-файл, которого нет в репозитории Maven?
- Скажите еще раз, откуда я взял этот плагин Eclipse.
Переходные зависимости
«Другое, меньшее, преимущество - обработка транзитивных и конфликтующих зависимостей.»
По моему опыту, переходные зависимости - это больше проблем, чем они того стоят. В итоге вы получаете несколько версий одного и того же файла JAR, и вы получаете дополнительные файлы JAR, которые вам не нужны. Я закончил тем, что объявил почти все с предоставленной областью, чтобы избежать хлопот.
Долгосрочная выплата
«Сосредоточьтесь на программировании, а не на построении».
Я согласен. С тех пор, как я вернулся в Ant и перевел мои jar-файлы в систему контроля версий, я смог потратить намного меньше времени на решение проблем сборки.
Вот те вещи, на которые я трачу меньше времени:
- Чтение плохой документации Maven.
- Чтение даже более бедной документации Codehaus Mojo.
- Настройка общих внутренних репозиториев.
- Обучение членов команды.
- Написание плагинов Maven для заполнения пробелов.
- Попытка обойти неисправные плагины (выпуск, сборка).
- Установка плагинов Eclipse для Maven.
- Ожидание, пока плагин вернет мне контроль над Eclipse.
В любом случае, извините за длинную публикацию. Может быть, теперь, когда я снял это с моей груди, я смогу завершить свой долгий и мучительный опыт с Maven. :)