Intereting Posts

Как разделить проект JSF для разработчиков против UI-кодеров при использовании Git в качестве репозитория кода

Я переношу приложение JSF в Cloudbees – в основном, на платформу Maven / Jenkins / Git. К сожалению, у меня нет большого опыта работы с Maven / Jenkins / Git.

Я хочу создать простой способ, чтобы разработчики пользовательского интерфейса могли синхронизировать с xhtml и связанными с ним файлами пользовательского интерфейса, не требуя кода Java на своих машинах. Разработчикам Java понадобится код UI и код Java. В обоих случаях, когда они подталкивают свой контент, он должен быть интегрирован с непрерывным процессом сборки Jenkins.

Есть ли хороший образец или предложение, которое вы могли бы сделать для разделения проекта, чтобы разработчики пользовательского интерфейса имели свои XHTML и другие файлы (изображения, CSS и т. Д.), В то время как у разработчиков Java есть все? Это нужно будет работать с Maven, Git и Jenkins. Спасибо за помощь.

Последнее: разработчики java будут использовать Eclipse. Разработчикам пользовательского интерфейса не нужно использовать Eclipse, поэтому ссылка будет Git.

Это действительно вопрос Maven / JSF. Дженкинс действительно не входит в уравнение, и CloudBees также не заметил (обратите внимание, что [cloudbees] также поддерживает размещенные репозитории Subversion, которые могут или не могут соответствовать вашей структуре проекта лучше … в любом случае GIT является ИМХО «лучше», поэтому я бы пошел на GIT над Subversion, если бы это был я)

У вас есть три варианта.

  1. Храните XHTML в отдельном репозитории GIT

  2. Храните все в одном хранилище.

  3. Вид смеси 1 и 2

Опция 1

Это приведет вас к дороге подмодулей GIT … это тот случай, когда я буду одобрять Subversion над GIT … и нет, я не имею в виду, что svn:externals лучше, чем GIT, более того, Subversion позволяет вам проверьте часть репозитория, поэтому команда пользовательского интерфейса может просто проверить подпункт, в котором живут файлы XHTML, IOW

 $ svn co https://svn-user1530669.forge.cloudbees.com/jsf-app/trunk/web-module/src/main/webapp web-content $ cd web-content 

будет работать для команды пользовательского интерфейса и

 $ svn co https://svn-user1530669.forge.cloudbees.com/jsf-app/trunk jsf-app $ cd jsf-app $ mvn package 

будет работать для разработчиков Java.

Для достижения такого же результата с GIT требуется использование подмодулей, поэтому у вас будет один подмодуль в web-module/src/main/webapp в web-module/src/main/webapp jsf-app.

Там, где это становится больно, когда разработчикам Java необходимо также настраивать файлы XHTML, в зависимости от IDE это может быть сложно, чтобы заставить коммиты в подмодуле правильно принимать. Кроме того, теперь у вас нет единственной ревизии для отслеживания, два репозитория могут перемещаться независимо … что может ухудшить некоторые особенности GIT.

Если вы хотите использовать плагин релиза Maven (и вы должны захотеть), Submodules предотвратит вас, так как идея модуляции меток не поддерживается плагином выпуска, и есть два отдельных репозитория для повторной проверки проблемы.

Вариант 2

Это действительно лучший вариант … хотя он делает именно то, что вы сказали, что не хотите делать.

Трюк здесь заключается в том, чтобы облегчить жизнь разработчиков UI.

Вы должны настроить хороший профиль Maven с целью по умолчанию, которая заканчивается запуском веб-приложения, например, приложением: запустить см. Например. Этот профиль pom. Если вы посмотрите этот проект и просто запустите

 $ mvn -Pdemo 

Он запустит веб-приложение из подмодуля, построив все зависимые модули.

Использование этого подхода означает, что ребята из UI могут также протестировать изменения пользовательского интерфейса, интегрированные в приложение JSF, уменьшающие нагрузку на Java-парней.

Вариант 3

Это своего рода смесь, у вас есть отдельные модули GIT для XHTML и Java, но они являются действительными проектами Maven.

Вы можете достичь этого двумя способами …

  • Пусть XHTML-модуль будет <packaging>war</packaging> который извлекается в веб-приложение Java с использованием Maven War Overlays

  • Имейте XHTML-модуль <packaging>war</packaging> которая напрямую связана с Java-зависимостями.

Первое имеет то преимущество, что разработчики Java могут быстро работать с кодом Java, но побочным эффектом является исправление XHTML, это сложно, например, атрибуты привязки данных

Второй делает более сложную настройку Java (необходимо продолжать работу по mvn install ), ребятам из UI приходится вытаскивать Java .JAR из удаленного репозитория Maven, если они хотят развернуть упаковку Maven, и, следовательно, вы можете выставить некоторые из своих java для пользовательских интерфейсов.

TL; DR

Лично, если не держать вещи в тайне от пользовательского интерфейса, это важно, я бы выбрал вариант 2