在m2eclipse中启用了作用域“测试”和工作区解析的Maven依赖关系-仅在Maven构建之后才显示编译错误

Question

This question is a result of an answer to the following question: Injection of an autowired field failed in a multi-module Maven project - NoSuchBeanDefinitionException

According to the answer from the aforementioned question, I configured the following structure of my Maven modules:

In this case, the class Foo from the base module can be used in tests in the module A (eg when it's autowired using the IFoo interface), but can't be used in the production code (which is contained in src/main/java).

The Maven build fails when someone adds a reference to the Foo class in a class in the module A in the production code (under src/main/java). However, the automatic build in Eclipse doesn't fail in such case, because I use the m2eclipse plugin which has the Workspace Resolution enabled. I have to run the maven buiild (mvn clean install) to see the compilation failure. Afterwards, the error is still not immediately visible in the affected class in Eclipse. I have to make a change in the affected java class (eg add a space and save the file) and then I can see an error in this class. However, what is even more misleading, is the fact, that the compilation error shown in Eclipse has nothing to do with the real copilation error. - The compilation error is shown in the next line after the erroneous line.
I don't want to disable the Workspace Resolution in the m2eclipse plugin, so that the newest sources are always used for the Eclipse's compile. However, it would be nice to see such compile error immediately in Eclipse and not have to perform a Maven build in order to see that compile error in Eclipse.

Is it possible to see the compile error immediately after the Eclipse's compile?

Answer 1

I am not sure why you are facing a compilation error on Maven build. Please see a sample project on Github that demonstrates a multi-module Maven set up with the module relationships as shown in your post above.

• interface - This module is the base every other module depends upon and is analogous to base-api module in your post. It contains a single interface called IGreeter , similar in essence to the IFoo interface in your post;
• implementation - This module depends on interface and contains a single class Greeter that implements IGreeter . It is analogous to base module in your post. Note that there is no other code in this module, not even unit tests;
• service - This provides a fictional service layer and depends on interface . Additionally, it has a test scoped dependency on implementation . It is analogous to module A in your post. It contains a class called GreetingService and its associated integration test class GreetingServiceTest . The test can be run from the command line or from Eclipse;
• web - This provides a fictional application layer and depends on all the other modules. It uses GreetingService to display a greeting message to the user. Run it as mvn clean package tomcat7:run .

This sample shows how you can write business logic by depending only on certain interfaces ( service module). It shows how a specific interface implementation can be chosen during testing to prove that integration works.

This sample also shows how you can choose a specific implementation of an interface at runtime ( web module). If you had multiple implementations of IGreeter and wanted to use a specific one at runtime, you would add that as a dependency to the web module instead of adding the implementation module.