2010-02-25 3 views
2

В настоящее время я разрабатываю несколько веб-приложений с использованием Spring. Я использую Maven для создания и Git для контроля версий. На данный момент я пытаюсь найти способ разделить разработку некоторых вещей, используемых всеми веб-приложениями, например. У меня есть вспомогательные классы, которые одинаковы для всех проектов. Проблема в том, что я не хочу использовать только классы, но также файлы ресурсов и какой-то родительский POM, хотя он все еще не зависит от репозитория и может извлечь выгоду из Git.Как включить родительский проект Spring (с использованием подмодуля Git)?

Хотя я не в восторге от изменения системы сборки, я не являюсь настоящим поклонником Maven. В особенности концепция наследования и агрегирования - вот что ограничивает меня сейчас. Может быть, Айви - это вариант?

Я хотел бы дать вам краткий обзор моей установки:

Там какая-то родительского проекта, включая некоторые классы, файлы конфигурации Spring и другие ресурсы, такие как шаблоны, изображения и таблицы стилей. Назовем это base. Это не полная версия Spring Webapp и не будет развернута. Есть еще несколько проектов, которые наследуют от base и должны быть упакованы в WAR. Назовем их webapp1 и webapp2.

base, webapp1 и webapp2 имеют свои собственные Git репозиториев:

\ 
| 
|- base.git  (base's repository) 
| 
|- webapp1.git (webapp1's repository) 
| \ 
| base   (base used as a Git submodule) 
| 
|- webapp2.git (webapp2's repository) 
    \ 
    base   (base used as a Git submodule) 

Я хочу, чтобы иметь возможность изменить base сек код изнутри на WebApps с помощью подмодуль Git, а также быть в состоянии построить полностью функциональный WAR каждого веб-приложения, используя mvn package внутри каталога webapp.

Maven's parent или module не позволяют использовать динамический подход. Я не нашел способ использовать module, как это вообще, и с помощью parent для моих нужд сложный и статический: для каждого изменения base потребуется новая версия, которая должна быть перенесена в репозиторий, чтобы Webapp`s мог наследовать от нее ,

Возможно, я не совсем понял наследство Мейвена, но сейчас я довольно потерян.

Неужели кто-то достиг чего-то подобного с успехом? Какую систему сборки вы использовали и как?

+0

- это базовый простой JAR, который необходимо упаковать в файлы WAR? –

+0

Нет, это не так. Как упоминалось выше, я также хочу включить какую-то «конфигурацию мета-сборки». Что может быть достигнуто с родительским ПОМ. Есть несколько задач, которые должны выполняться для всех проектов, и я не хочу их копировать и вставлять. – Koraktor

ответ

0

Я нашел рабочее решение самостоятельно.

Основным решением моей проблемы является небольшой подэлемент элемента <parent> под названием <relativePath>. Он позволяет искать родительский POM в указанной директории. В противном случае вам всегда нужно будет развернуть новую версию, прежде чем вы сможете ее протестировать в своем приложении.

<parent> 
    <groupId>com.example</groupId> 
    <artifactId>base</groupId> 
    <version>1.0.0</groupId> 
    <relativePath>base</relativePath> 
</parent> 

Но это была только отправная точка, позволяющая работать с подмодулем Git. Для того, чтобы получить это на самом деле работает, мне нужно сделать следующее:

  • Создание WAR с классами и ресурсы из обоих, веб-приложение и base, то есть все файлы внутри

    base/src/main/java 
    base/src/main/resources 
    base/src/main/webapp 
    src/main/java 
    src/main/resources 
    src/main/webapp 
    

    Хотя ресурсы довольно легко для покрытия, требуется немного конфигурации для org.apache.maven.plugin:maven-war-plugin, чтобы получить ресурсы webapp в WAR. Для компиляции двух разных исходных папок требуется плагин, поэтому мне нужно использовать org.codehaus.mojo:build-helper-maven-plugin, чтобы получить классы base в WAR.

  • Кроме того, я использовал много фильтров для ресурсов, поэтому практически нет необходимости в настройке основных файлов для запуска и запуска веб-приложения. Например, я использую ${project.artifactId} внутри мой главный файл шаблона, так что мой HTML <head> будет выглядеть примерно так на веб-приложение под названием webapp1:

    <link href="stylesheets/base.css" rel="stylesheet" media="screen" type="text/css" /> 
    <link href="stylesheets/webapp1.css" rel="stylesheet" media="screen" type="text/css" /> 
    

Он действительно взял много проб и ошибок, но наконец-то я заставил его работать, и я думаю, что это лучший способ достичь моей цели, используя Maven. Это было бы намного проще с помощью динамического инструмента, такого как Buildr, но, к сожалению, Buildr медленно работает на Windows (благодаря Ruby) и не очень хорошо интегрируется в большинство IDE.

0

Ваш случай использования кажется хорошим вариантом для overlays (также смотрите на the examples).

Наложения используются для совместного использования общих ресурсов по нескольким веб-приложениям. В общем, все зависимости проекта WAR собраны в WEB-INF/lib, за исключением артефактов WAR, которые накладываются на источник WAR.

Но база не будет «под» модулем WebAPP, было бы очень вероятно, будет модуль родственный (возможно, это может быть «в» веб-приложение, используя Гаденыш черную магию, но это выходит за рамки моего Git и я не понимаю, как это можно было бы решить с Maven). Нет, на самом деле, я думаю, что Maven будет использовать оверлеи. И если это не то, что вы хотите, лучше используйте что-то другое, чем Maven IMO.

+0

Это похоже на лучший подход, чем то, что я завербовал с наследованием Maven, используя 'parent'. Но ему не хватает, ну, наследства. Объединение обоих параметров приведет к аналогичной раздутой конфигурации без динамики и поддержки интеллектуального рабочего процесса Git. Кажется, что Maven не так хорошо играет с Git (и особенно подмодулями Git). Я уже изучаю альтернативы, и, как и раньше, я открыт для предложений. – Koraktor

+0

@ Koraktor Maven хорошо играет с Maven, вы должны следовать его правилам. То, что вы хотите сделать, невозможно с Maven: вы не можете наследовать от проекта, у которого нет пакета 'pom' (я не понимаю, зачем вам наследование между webappX и базовым BTW). Вам нужно что-то полностью настраиваемое здесь, например, задачи Ant + Maven Ant или Ant + Ivy (вы не хотите компилировать «базу» дважды, я думаю, вам нужна специальная логика сборки). Но, честно говоря, я вижу больше того, что вы теряете, чем то, что вы выигрываете с помощью своего «умного рабочего процесса Git». –

Смежные вопросы