[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-dev] Problem with classifiers - Compilation classpath and test classpath behaves inconsistently
|
I understand the problem but I am not sure changing one bad behaviour
with another is a good idea. Debugging problems with unexpected
classes/resource on classpath will be as frustrating as debugging
problems with missing classes/resource and I have no data to suggest one
set of problems will be more or less likely than the other.
--
Regards,
Igor
On 2013-05-21 10:45 AM, Lincoln Baxter, III wrote:
Hello Everyone,
I have discovered a problem with the treatment of classifiers by m2e.
As we are all aware, Eclipse has only a single classpath concept, and to
work around this, m2e merges both test and compile classpaths into one
big classpath so that eclipse can compile everything in src/main and
src/test successfully. (Otherwise we would get lovely red X's in tests
that depend on "test" scoped dependencies.) Classifiers are also ignored
here for projects in the workspace, and all classes from a classified
workspace dependency are added to this classpath.
To the point, this is not the case when launching JUnit test
configurations "Run As -> JUnit Test"
In this case, m2e actually sets the JUnit classpath to omit any
classified dependency projects that in the case of non-classified
dependencies, are resolved normally via workspace resolution.
I can provide simple steps to reproduce if you would like to see the
problem first-hand.
*In effect:*
* Eclipse compile time: Classified workspace dependencies are on the
classpath.
* Eclipse JUnit launch: Classified workspace dependencies are *not* on
the classpath.
*Summary:*
* Eclipse compilation succeeds. Everything looks good, no problems
reported in workspace.
* JUnit run fails to launch. Caused by:
java.lang.ClassNotFoundException for classes that should be provided
by the classified workspace project dependency.
*Problems:*
While I understand that it is actually difficult to determine the actual
classes that should be on the classpath, without having access to the
final classified JAR, this introduces an extremely odd and difficult to
debug situation for the user. A Maven CLI build is the ultimate source
of truth, and since m2e has already "cheated" and merged classpaths to
work around the eclipse compile classpath issue, I find it is far more
confusing to add yet another level of inconsistency. In this case, m2e
is inconsistent with its own inconsistency with Maven. And that's
starting to be exponential inconsistency, which isn't good ;)
To add additional frustration, unlike the eclipse "Maven Dependencies"
classpath entry, the test-classpath is only visible when editing the
launch configuration; therefore, even finding the problem is difficult -
who would think to edit the junit launch config for your project to
solve: "Caused by: java.lang.ClassNotFoundException" ?
Most of the time, when depending on a classified artifact, you want
something out of that artifact, otherwise you would not depend on it at
all. Because m2e basically says, "It's classified, and I don't know
what's in it so I'm not going to include it," it basically breaks 100%
of all classifiers on the test classpath, instead of breaking 1%, which
would be caught by the mvn CLI build anyway, and letting the 99% succeed.
*Recommendation:*
*
*
Anyway, I'm not sure if this was intentional or just an oversight, but
my recommendation would simply be to make the m2e test classpath behave
like the compile classpath already does. It does not make sense to do
otherwise IMO - it's feels inconsistent and weird..
Thanks for taking a look!
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev
