tags:

views:

242

answers:

3

I have three modules in my Maven project (this is slightly simplified):

  • model contains JPA annotated entity classes
  • persistence instantiates an EntityManager and calls methods on it
  • application creates instances of the classes in model, sets some values and passes them to persistence

model and persistence obviously depend on javax.persistence, but application shouldn't, I think.

The javax.persistence dependency is moved to a top-level POM's dependencyManagement section because it occurs in a number of submodules where I only reference that entry.

What's surprising to me is that I have to reference the dependency in application when I set its scope to provided, whereas I don't have to when its scope is compile.

With a scope of provided, if I don't list it in the dependencies for application, the build fails with an error message from javac:

com.sun.tools.javac.code.Symbol$CompletionFailure: class file for javax.persistence.InheritanceType not found

What's going on?

+1  A: 

The dependencyManagement section declares what dependencies will look like if you use them, not that you will use them. So you still need to declare a minimal dependency declaration to have the configuration applied in your child project. See the dependency management section of the Maven book for details.

The minimum required is typically the groupId and the artifactId.

If you want to inherit the configuration without declaring it at all, you should define it in the parent's dependencies section rather than dependencyManagement

Rich Seller
Yes, I know that. What I'm wondering is, why is the one module dependent on `javax.persistence` at all, when it's really just a transitive dependency that should be resolved by Maven? I'll try and clarify my post a little.
Hanno Fietz
@Hanno No, it shouldn't. See my answer.
Pascal Thivent
+1  A: 

model and persistence obviously depend on javax.persistence, but application shouldn't, I think.

That's true. But transitive dependencies resolution has nothing to do with your problem (and actually, javax.persistence is provided to model and persistence on which application depends with a compile scope so it's omitted as documented in 9.4.4.1. Transitive Dependencies and Scope).

In my opinion, you are victim of this bug: http://bugs.sun.com/view_bug.do?bug_id=6550655

I have the same issues with an EJB3 entity that uses the Inheritance annotation: @Inheritance(strategy=InheritanceType.SINGLE_TABLE)

A client class using this entity won't compile when the ejb3 annatations are not on the classpath, but crash with the following message: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for javax.persistence.InheritanceType not found

[...]

Note that is a special case of bug 6365854 (that is reported to be fixed); the problem here seems to be that the annotation is using an enum as its value.

The current workaround is to add the missing enum to the CLASSPATH.

In your case, the "less worse" way to do that would be to add javax.persistence as provided dependency to the application module. But that's a workaround to the JVM bug, application shouldn't need that dependency to compile.

Pascal Thivent
Are you really sure that my problem is not that I didn't read the Maven manual properly? Maybe there's a bug in that the error message should be different, but in any case, the required class files are hidden because Maven *intentionally* doesn't include them in the class path.
Hanno Fietz
My point is that you don't need `javax.persistence.*` to compile the application module and shouldn't have a compilation error.
Pascal Thivent
Well, I'm confused. :) You're right in that I shouldn't get the compile error, I guess. At least that would be my gut feeling. But I'll have to think a little harder about how my scopes affect each other, and whether I really grokked the table you linked to.
Hanno Fietz
I clarified my answer (about the fact that this compilation error is a JVM bug).
Pascal Thivent
+1  A: 

umm, because provided dependencies are not transitive? that's builtin behavior for maven.

james
umm - you're right. duh.
Hanno Fietz
That's not absolutely exact. If `project-a` contains a provided scoped dependency on `project-b` which contains a provided scoped dependency on `project-c`, `project-c` would be a provided-scoped transitive dependency of `project-a`. Again, see http://www.sonatype.com/books/maven-book/reference/pom-relationships-sect-transitive.html#pom-relationships-sect-transitive-scope
Pascal Thivent
@Pascal - wow, you learn something new every day! don't think i've ever run into that little nugget in an actual project before, though.
james
@Pascal - thanks for being insistent. I'll have to think a little harder about it, I'm not sure if I got it straight, now.
Hanno Fietz
@Hanno - his point doesn't affect your situation. he was only saying that if you have a string of provided deps, the transitivity still holds. in your situation, you do not have (nor want) provided dependencies within your own modules, so this side point is not relevant.
james
@James yes, you got it
Pascal Thivent