m2e: Папка, содержащая java _sources_, должна использоваться несколькими проектами m2e

Question

У меня возникла ситуация, когда мне нужна папка, содержащая источники Java, используемые в качестве исходной папки для нескольких проектов maven «рядом друг с другом» в древовидной структуре , Из-за различий в зависимостях для maven projets я не могу создать артефакт, содержащий скомпилированную версию источников, но для каждого проекта рассматривайте его как исходную папку в дополнение к src/main/java.

Очевидно, что Maven может сделать это легко, добавив другую папку источника, расположенную в «../foo/src», но m2e отказывается это делать, и для этого хорошо работать для нас, мне нужно, чтобы она работала в Eclipse ,

Как я пошел бы на имеющий структуру, как:

/common/src 
/a/pom.xml (add source folder ../common/src) 
/a/src/main/java/... 
/b/pom.xml (add source folder ../common/src) 
/b/src/main/java/.... 

и получить его работу в Eclipse?

(примечание: Я знаю http://dev.eclipse.org/mhonarc/lists/m2e-users/msg01988.html - это, однако, начиная с 2011 года)

Answer 1

Вы должны быть в состоянии использовать относительные пути и Maven Build Helper в виде раствора.

В каждом проекте, или в «родительский» pom.xml, что все они унаследованы из добавьте следующее:

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>build-helper-maven-plugin</artifactId> 
    <version>1.8</version> 
    <executions> 
     <execution> 
     <id>add-source</id> 
     <phase>generate-sources</phase> 
     <goals> 
      <goal>add-source</goal> 
     </goals> 
     <configuration> 
      <sources> 
      <source>${basedir}/../../common/src</source> 
      </sources> 
     </configuration> 
     </execution> 
    </executions> 
    </plugin> 

Answer 2

Как насчет небольшого трюка с файловой системой? Просто сделайте символические ссылки на папки, и вы, вероятно, будете в порядке :)

Для NTFS вы можете попробовать сделать mklink из командной строки. Больше объяснения здесь: http://en.wikipedia.org/wiki/NTFS_symbolic_link

Answer 3

Если вы используете Subversion, вероятно, наиболее удобный подход будет держать общую исходную папку в отдельном хранилище и добавить его ко всем проектам, которые нуждаются в ней посредством svn:externals. С другой стороны, это упростит создание тегов и ветвей.

Возможно, что-то подобное может быть достигнуто с субрепозиториями Mercurial, но это было бы не так удобно.

Answer 4

Вы должны не сделать это.

Если вы хотите использовать этот код в разных модулях, то он также должен быть модулем Maven, используемым в качестве зависимости другими модулями.

Основная проблема с тем, что вы пытаетесь сделать, заключается в том, что даже если это не фактическая копия/вставка источников между двумя модулями, в конце она ведет себя как одна. Что произойдет, если вы построите две банки? У вас будут повторяющиеся классы, поэтому, если вы используете их в одном приложении, путь к классам будет немного неправильным.

Итак, что именно вы пытаетесь достичь?

• Повторное использование кода в двух отдельных модулях? Затем используйте его как зависимую банку.
• Код повторного использования в двух разных модулях, но вы не хотите, чтобы в итоге было несколько банок? Затем вы можете использовать maven-shade-plugin для встраивания зависимости в конечный артефакт.
• Создайте две несколько разные версии одной и той же библиотеки? Затем вы можете снова использовать плагин maven-shade для расширения одной банки с дополнительными источниками.Или вы можете использовать aspectj-maven-plugin для ввода аспектов в базовый набор классов.
• У вас есть код, который вызовет циклическую зависимость, поскольку модули зависят от общего кода, который, в свою очередь, зависит от кода от каждого модуля? Правильное исправление будет состоять в том, чтобы извлечь общий модуль API из модулей, который войдет в общую зависимость и будет выполняться по-разному каждым модулем.

Если вам действительно нужно хранить его как общий исходный каталог вместо общей зависимости, вы можете посмотреть this answer.

Answer 5

Почему бы просто не сделать общий lib a Maven <dependency /> в других проектах «pom.xml» и использовать функцию «Разрешить зависимости от проектов рабочей области» в m2e (которая, по моему мнению, является дефолтом) в зависимых проектах (справа) нажмите project => project properties => Maven)?

Таким образом, зависимые проекты автоматически будут видеть классы общей библиотеки lib внутри IDE, без необходимости создавать/устанавливать общий артефакт lib в репозиторий maven (локальный или удаленный).

Поскольку вы используете Git, ветвление, скорее всего, облегчит вам предоставление различных версий (версия, как в файле pom.xml) общей библиотеки lib, и соответствующим образом ссылается на эти версии в зависимых проектах «<dependency />».

Answer 6

Я бы использовал NTFS Junction.

Я использую их в своих проектах для совместного использования ресурсов между проектами, фактически не копируя их. Соединение подобно черной дыре между приводом и файловыми системами. Они ведут себя так же, как и жесткие ссылки, но могут ссылаться на папки, даже на разных дисках (включая сетевые диски). С вашей точки зрения, это будет выглядеть как папка/common/src в папке ваших проектов (тогда вы можете сказать Eclipse использовать ее как исходную папку). Конечно, вы можете переименовать точки соединения, так что/common/src, как видно по проекту a, будет называться common.

/common/src 
/a/src 
/a/common <- this is a junction to /common/src 

Чтобы облегчить создание соединения, я очень люблю использовать this shell extension.