在Eclipse m2e中，如何引用工作区项目？

Question

How can I reference another workspace project using Eclipse m2e ?

Do I have to add a project dependency in the project setting? But in that case the dependency is not shown in the pom.

If I set them in the pom, it will not reference the project in workspace but reference the jar in the local repository. Quite annoying, anyone can help?

Answer 1

The correct way to do this is the following:

• Use the dependencies section in the POM file exclusively, don't fiddle with the Eclipse project references. Right-click the project, then select Maven > Update Project Configuration to reset the project to the Maven default settings. This way, m2e has ownership of the dependencies.
• Make sure all referenced projects are open in Eclipse and have the Maven nature enabled.
• Check the Maven settings for each project, make sure that groupId , artifactId and version match with the projects you have open in Eclipse. So if the project you depend on has version 1.0.0-SNAPSHOT in Eclipse, make sure that the depending project's POM file references version 1.0.0-SNAPSHOT in the dependencies section.
• Enable Workspace Resolution for each of the projects. Right-click the project, then Maven > Enable Workspace Resolution .
• Finally, if the projects are still not resolved, right-click the project again, then Maven > Update Project

This should solve your problem. If after this, your dependencies are still referenced from the file system, check the groupId , artifactId and especially version of each dependency again.

Also check if you don't have any errors in your project - try to run Maven install.

Answer 2

I'd go even further than this. If you've ever run mvn eclipse:eclipse on your project then you're probably in trouble. I had a situation where I had both a " Referenced Libraries " section and a " Maven Dependencies " section in my eclipse project, with conflicting library versions, causing eclipse and myself inevitable confusion.

The safest thing I found was to run mvn eclipse:clean from the command line then go back in to eclipse, refresh the project, "OK" the resulting problem dialog, and then go Maven > Update Project . This sorted it all out for me.

Answer 3

When eclipse is messed up with importing and deleting several projects, you may need to rebuild index of maven repositories. Here is a way that I have done.

1. Check if an referenced project is recognized as a maven project by eclipse properly.

   In menu bar, click Window -> Show View -> Other...
   When 'Show View' window pops up, select Maven -> Maven Repositories
   In Maven Repositories window, You should see your project as jar file in Local Repositories -> Workspace Projects
   If you can not find your project in Workspace Projects , right click on Workspace Projects and select Rebuild Index .

2. Update maven of an referencing project

   Right click on the referencing project, Maven -> Update Project... -> OK

Answer 4

You also need to make sure that you are running the correct goals.

If you don't run the install goal then it won't be copied to your repository and won't compile.

To learn more about goals have a look at https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

Answer 5

With kudos to @nwinkler's response, the main problem is matching the version number.

A common scenario is that if you are developing a set of projects that are version lock-steped with each other - for example, a project and a set of library projects that are not very loosely coupled, such that a library API might change in a version to be consumed by the relevant app project version, but may change in a way that is incompatible with a past or future version of the app project.

The correct way to set Maven dependencies in such a configuration (and it is also the recommended practice) is to have the app consume specific versions of the libraries - so, for example, if you rebuild an old version of the app, it will use the library version that it previously compiled with.

With the app project's POM library dependency set to a release version (lets say 1.0.0 ), and while working on the next release with both the app and library projects set to a SNAPSHOT release (lets say 2.0.0-SNAPSHOT ), the m2e will not resolve the library version correctly, and will likely download an old version, so that trying to use Eclipse features like "Open Decleration" will target the download jar (sometimes without even a source attachment) which can be pretty annoying.

One way to work around that is to set the app POM dependency version to a range, so instead of depending on 1.0.0 , you'd depend on [1.0.0-) . With an open range like that, m2e will happily find your workspace library project. But you'd want to set it back to the "correct" version before committing, building and publishing - and this can be very error prone.

My solution is to use build profiles and set a custom profile for m2e, like this:

• Set your dependency version with a property, to the version you want to publish against:

...

<properties>
<my.library.version>1.0.0</my.library.version>
</properties>

<dependencies>
  <dependency>
    <groupId>my.group</groupId>
    <artifactId>my.library</artifactId>
    <version>${my.library.version}</version>
  </dependency>
</dependencies>

...

• Then add a profile section with an active by default profile that does nothing, and an Eclipse-specific profile that overrides the library version property with a range:

...

<profiles>
    <profile>
        <id>default</id>
        <activation><activeByDefault></activeByDefault></activation>
    </profile>

    <profile>
        <id>eclipse</id>
        <properties>
            <my.library.version>[1,)</my.library.version>
        </properties>
    </profile>
</profiles>

...

• Finally go to your project properties, and under "Maven" type "eclipse" into "Active Maven Profiles":

• Then "Apply and close".

Eclipse m2e will then always see the version range and will resolve dependencies from the eclipse project (even if you have the library installed in the local Maven repo, as the Eclipse project will have a higher version number), but other builders will see the original, strict, version number.