Мультипроект Java Flat с быстрой инкрементной компиляцией и оперативным развертыванием кода - WTP? Затмение? IDEA? Maven? Gradle?

1

У нас есть достаточно большая взаимозависимая многопроектная база кода, в которой в настоящее время используется Java7 & Groovy, построенная с использованием Eclipse/WTP & Ant под управлением Tomcat 7. В принципе, что-то, что вы найдете в возможно большей части разработки программного обеспечения Java Enterprise. Мы модифицировали наш процесс сборки на протяжении многих лет, но он довольно хрупкий в Eclipse, Ant-only build работает отлично, хотя и медленно:

  • Рабочее пространство
    • банки
    • общий
    • common-web (зависит от источника)
    • web1 (зависит от общего Интернета, общий)
    • web2 (зависит от общего Интернета, общий)
    • web3 (зависит от общего Интернета, общий)
    • cli-app1 (зависит от общего)
    • cli-app2 (зависит от общего)

Мы использовали исключительно Ant, создавая common.jar, common-web.jar и т.д. И копируем в webN/WebContent/WEB-INF/lib. Это работало, но было медленным, и замена горячего кода и инкрементная компиляция невозможны (по крайней мере, для общих изменений *).

Теперь мы разрешаем Eclipse/WTP компилировать и собирать статические ресурсы. Общие и общие веб-проекты добавляются в сборку развертывания как виртуальные банки, чтобы предотвратить время, затрачиваемое на создание баннеров. Ant все еще выполняет некоторые шаблоны и копирование динамических ресурсов, а также копирует все внешние банки в WEB-INF/lib (это выполняется Ant по сравнению с библиотеками Eclipse/Web App, поэтому нам нужно поддерживать только наш список баннеров в одном месте, build.xml, а именно, что необходимо поддерживать их отдельно для каждого проекта в Eclipse в дополнение к build.xml для производственных сборок). После завершения Ant автоматически обновляет папки WEB-INF/lib и WEB-INF/classes, чтобы Eclipse/WTP знал об обновленных файлах.

Для развертывания на сервере мы просто позволяем Ant обрабатывать как компиляцию, так и сборку.

Наша стратегия позволить Eclipse/WTP иметь дело с автоматическим инкрементным построением и публикацией в Tomcat для разработки, сократила время компиляции Ant только в 2+ до практически мгновенного и разрешила замену горячих кодов обычных * классов. Однако эта настройка очень хрупка, поскольку любое изменение файла в файловой системе без знания Eclipse ломает сборку. Это также означает, что наша настройка проекта сложна и, следовательно, ее необходимо проверить, что, конечно же, означает, что она часто ломается, так как коллеги случайно проверяют локальные изменения.

Должен быть лучший способ легко работать с плоскими многомодульными проектами в среде IDE

Я посмотрел на maven и gradle, но оба признали, что когда дело доходит до плоских мультимодульных настроек, они просто не работают (или они?). Вложение невозможно из-за нескольких проектов верхнего уровня, требующих одинаковых подмодулей. Да, вы можете поместить корень pom.xml или gradle.settings в папку над проектами, но это не позволяет осуществлять бесшовное управление конструкцией/зависимостью Intellij или Eclipse, поскольку эта папка не видна.

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

Мы рады изменить инструменты сборки или даже IDE, если есть целая цепочка инструментов, на которой можно эффективно собирать и собирать, не покидая среду разработки и быстро.

В принципе, то, что мы делаем, "просто":

  • Автоматическое управление зависимостями
  • Быстрый, инкрементный компиляция во время разработки
  • Смена Hot-Code (WTP/JRebel Style)

ТАК, вы можете помочь?

  • 0
    Что именно вы подразумеваете под: I have looked into maven and gradle but both admit that when it comes to flat multi-module setups they just don't work (or do they?). ?
  • 0
    В документации Maven говорится, что плагин релиза не работает с плоской многомодульной установкой. Билет на ( jira.codehaus.org/browse/MRELEASE-261 ) закрыт и помечен как исправленный, однако есть несколько недавних комментариев, в которых говорится, что синица все еще не работает. И насколько я читал, вам понадобится
Показать ещё 1 комментарий
Теги:
maven
gradle
eclipse-wtp

1 ответ

0

В градиенте вы можете иметь разные настройки.gradle в каждом из своих модулей, например: в web1, добавить settings.gradle, которые имеют:

include ':common'
project(':common').projectDir = "../common" as File
include ':common-web'
project(':common-web').projectDir = "../common-web" as File

то вы можете добавить зависимости в build.gradle как:

 compile project(':common')
 compile project(':common-web')

gradle может помочь вам:

  • Автоматическое управление зависимостями
  • инкрементная компиляция во время разработки, но она намного медленнее, чем ant в моем опыте
  • У градле есть плагин Jrebel, который может помочь заменить Hot-Code.

Gradle очень гибкий и управляемый по сравнению с maven, но он медленнее и имеет больше ошибок, чем maven, так как он намного моложе.

Поделиться
  • 0
    Благодарю. Официальный плагин Eclipse Gradle только помогает импортировать проекты в Eclipse, но фактически не создает, как это делает плагин STS . Но если Gradle выполняет сборку, сможет ли Eclipse / WTP по-прежнему использовать общие проекты в качестве виртуальных jar-файлов? Лучше ли интеграция Gradle с Eclipse или IntelliJ?
  • 0
    Оба плагина в настоящее время оставляют компиляцию в Eclipse. То же самое для IntelliJ. Насколько мне известно, плагины легко справляются с плоскими структурами каталогов. Все, что нужно, это использовать includeFlat вместо include в settings.gradle . Инкрементная компиляция Java Gradle является инкубационной функцией. Общая функция инкрементальной сборки сэкономит время.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню