Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

m2e: Folder containing java _sources_ need to be used by several m2e projects

I have a situation where I need to have a folder containing Java sources used as a source folder for several maven projects "next to each other" in a tree structure. Due to dependency differences for the maven projets I cannot create an artifact containing the compiled version of the sources, but need to have each project treat it as a source folder in addition to src/main/java.

Apparently Maven can do this easily by adding another source folder located in "../foo/src", but m2e refuses to do this, and for this to work well for us, I need to have it working in Eclipse.

How would I go at having a structure like:

/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/....

and get it working in Eclipse?

(note: I am aware of http://dev.eclipse.org/mhonarc/lists/m2e-users/msg01988.html - it is, however, from 2011)

like image 746
Thorbjørn Ravn Andersen Avatar asked May 24 '13 11:05

Thorbjørn Ravn Andersen


4 Answers

You should not do that.

If you want to use that code in different modules, then it should also be a Maven module, used as a dependency by the other modules.

The main problem with what you're trying to do is that even though it is not an actual copy/paste of sources between the two modules, in the end it behaves like one. What would happen once you build the two jars? You'll have duplicate classes, so if you use them in the same application the classpath will be a bit wrong.

So, what exactly is it that you're trying to accomplish?

  • Reuse some code in two distinct modules? Then use it as a dependent jar.
  • Reuse code in two distinct modules, but you don't want to end up with multiple jars? Then you can use the maven-shade-plugin to embed the dependency in the final artifact.
  • Build two slightly different versions of the same library? Then you can again use the maven-shade-plugin to extend one jar with additional sources. Or you can use the aspectj-maven-plugin to inject aspects into a base set of classes.
  • Have a code design that would trigger a circular dependency, since the modules depend on the common code, which in turn depends on code from each module? The proper fix would be to extract a generic API from the modules, which would go into the shared dependency and would be implemented differently by each module.

If you really, really have to keep it as a shared source directory instead of a shared dependency, then you can look at this answer.

like image 162
Sergiu Dumitriu Avatar answered Nov 22 '22 04:11

Sergiu Dumitriu


How about a little trick with the file system? Just make symlinks to the folders and you probably be fine :)

For NTFS you can try to do mklink from command line. More explanation here: http://en.wikipedia.org/wiki/NTFS_symbolic_link

like image 30
WeMakeSoftware Avatar answered Nov 22 '22 06:11

WeMakeSoftware


You should be able to use relative paths and Maven Build Helper as a solution.

In each project, or in a "parent" pom.xml that they all inherit from, add the following:

  <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>
like image 35
noahlz Avatar answered Nov 22 '22 06:11

noahlz


If you use Subversion probably the most convenient approach would be to keep the shared source folder in a separate repository and add it to all the projects that need it by means of svn:externals. On the other hand this would make creating tags and branches more complicated.

Something similar could probably be achieved with Mercurial sub-repositories, but it wouldn't be as convenient.

like image 20
Nicola Musatti Avatar answered Nov 22 '22 06:11

Nicola Musatti