Curious classpath problem with a legacy sub-project

I don’t know if the following problem is a Gradle problem that should get a solution or if it’s just a problem of mine.

This is the situation: I have a legacy sub-project (which is a dependency for other sub-projects) consisting of a legacy Jar and some source classes. The curiousity is that these source classes have exactly the same full qualified names (package name + class name) as some of the classes residing in the jar. Yes, that’s a horrible mechanism overriding classes living in a dependency jar, but some people did it.

Therefore, the build has to do a rewrite of this jar, effectively overwriting existing classes in the jar with the ones just compiled by the build. So far, this is more than ugly, but it works.

But then I discovered - because of a compile error I got - that some project uses just classes from the source classes of this project and some other classes from the legacy jar. So the situation is: this project declares a project dependency on the project and a library dependency on the legacy jar. So I think I get the compile error because Gradle cannot make a difference and overrides the source class with the class from the jar. Somekind of namespace clash. To test if it worked removing the conflicting classes from the jar, I got compile success.

As said, I do not know if this should be declared as a Gradle problem, but I want to report it.

(btw: I use Gradle 1.6)

When you have duplicate classes on a class path, the one that comes first wins. Gradle doesn’t guarantee any particular file order for a resolved configuration. Can’t all projects just use the patched Jar? This would avoid duplicate classes in the first place, which is the best solution.

thanks for your kindly response, Peter.

Indeed, we should change this situation, there are ways to do it (I have to convince the technical lead). I just wanted to hear what the Gradle folks are thinking on this conflict; might have been that this showed some weakness.