views:

546

answers:

3

Ok, so I'm getting a little annoyed with Maven 2 right now. The project setup we've got is simple: A "core" project, which is depended on by both a "batch" and "web" project, and an "ear" project which depends on "web". Pretty simple stuff.

Well, since core is used quite a bit, and this is the first time the group is actually doing TDD (test driven development), there's been quite a few mocks created, but mostly in the web project - the batch project is quite simple at the moment.

This current (obsfucated) XML is included in the web pom to include the core project as a dependency:

<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>XYZ-core</artifactId>
<version>${project.version}</version>
</dependency>

The pom works if just this is included, as well as the rest of the jar files included. One of the jar files included is the servlet api, 2.4 is the version:

<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>${version.servlet-api}</version>
<scope>provided</scope>
</dependency>

This is set to scope provided as it will be provided by the web container. No surprises there. With just that in the web pom, it runs the tests and installs no problem.

But, now there's all these mocks in web. Batch can use some of these mocks too. So, naturally I wish to place the core tests as scope test in both the batch and web, so I can move the mocks (which mock core functionality) into core's test so they can be shared among projects. The following snippet (obsfucated) works in the batch project:

<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>XYZ-core</artifactId>
<classifier>tests</classifier>
<version>${project.version}</version>
<scope>test</scope>
</dependency>

However, when I add this to the web pom, I get this all over when I try to build web.

XYZ.java:[33,16] cannot resolve symbol symbol : class HttpServletRequest

If it is removed, web builds successfully.

Any ideas? The maven version is 2.0.4. I can attempt an upgrade but this will mean a lot of hassle.

EDIT: The main classes of web are failing to compile with that error (also HttpServletResponse is not being found as well). Even if tests are skipped (-Dmaven.test.skip=true), this error happens.

A: 

This is not a problem with your maven distribution itself.

In general, use mvn dependency:tree when trying to troubleshoot why certain dependencies aren't being included in their expected artifacts or scope.

In your case, although you have the servlet-api artifact available as a provided dependency, you actually need an implementation available during the test phase. It sounds to me like the tests you are running in batch never import your mock classes that import anything from javax.servlet but your tests in web do import mocks that import something from javax.servlet - correct me if I am wrong there, of course.

I would consider adding some jetty implementations as a dependency with test scope and see if that gets you any further.

whaley
I don't believe core has any servlet dependencies but I may be wrong. If so, core needs to have its dependencies re-adjusted, as it is supposed to be common to both batch and web, but not concerned about either project (no particulars).
MetroidFan2002
Oh, sorry, I also forgot where the errors were occurring - main classes, this even fails when tests are skipped. I'll add this to the question.
MetroidFan2002
+1  A: 

You should check mvn help:effective-pom with and without the offending chunk.

You may also be getting bitten by this bug, but you'll have to see if it applies to your parentage situation.

In any case, you really should at least try it in a temporary area with maven 2.0.9 ... you can edit the maven start scripts so that it doesn't affect your existing repository, etc. Only way to know for sure that you're not getting hit by an already-resolved bug.

Zac Thompson
Interesting tidbit about effective pom. This issue was indeed solved by an upgrade to maven 2.0.9, although it's site plugin had issues and I had to manually set it back to version 2.0.
MetroidFan2002
+1  A: 

Maven 2.0.4 is three years old and predates a fairly critical change in the way Maven 2 interacts with plugin versions. Prior to Maven 2.0.9, a Maven build would download the latest version of all plugins required. You are likely running into an inconsistency because you are using a newer plugin with Maven 2.0.4. Before doing anything, update to anything above Maven 2.0.9 despite the hassle. I'm surprised you can still build with 2.0.4.

At this time, you should consider updating to either 2.0.10 or 2.1.0. The main difference is that 2.1.0 contains some parallel downloading improvments and support for encrypted server passwords.

tobrien