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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

В качестве решения вы должны использовать относительные пути и 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>

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

Я бы использовал соединение NTFS.

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

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

Чтобы облегчить создание Junction, мне очень нравится использовать это расширение оболочки.