| Re: [m2e-dev] Problem with classifiers - Compilation classpath and test classpath behaves inconsistently |
Hey Igor,Thanks for taking a look.I understand your concern, they are both technically incorrect - but wouldn't it make sense for compilation and testing to follow the same classpath? Otherwise there is an inconsistency, and that inconsistency exists solely in eclipse with m2e configured projects.It sounds like you are suggesting that debugging tests with unexpected classes on the classpath is somehow more surprising than with classes missing. I would argue that this is actually the opposite, because every indication from the "Maven Dependencies" classpath container suggests that the class does in fact exist. The project looks like it is correctly referenced from the user's point of view when viewing the project "Build Path", and "CTRL-3" links to that class take you to the referenced project, and so on. At least with this "one big classpath," people generally understand that Eclipse has a limitation, and accept it. They understand that there will be test classes on the classpath that are not available from a real maven build. Why reverse that concept just for this one scenario?Speaking of reversal, let's look at what happens when we reverse the scenario. Let's say we apply the same reasoning to the primary compile classpath: By this line of thinking, you would have compile errors in eclipse because classified dependencies are not available, but compilation would succeed in Maven. Does that make sense? I imagine not, otherwise m2e would enforce this and developing with maven and eclipse would be useless (without manual configuration.) That's the same scenario that exists today in tests.If there is no data to support either side, then why not at least favor the principle of least surprise, and make these two things behave the same way?~LincolnOn Tue, May 21, 2013 at 11:37 AM, <ggastald@xxxxxxxxxx> wrote:
FYI, this is the issue better describing this:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=368230
On 05/21/2013 11: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..
--
George Gastaldi | Senior Software Engineer
JBoss Forge Team
Red Hat
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."