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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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