Hey Igor, when do you have some time when we could chat about this issue
on IRC or other medium?
Thanks!
Lincoln
On Tue, May 21, 2013 at 12:24 PM, Lincoln Baxter, III
<lincolnbaxter@xxxxxxxxx <mailto:lincolnbaxter@xxxxxxxxx>> wrote:
Not to mention, there is no way to actually add "parts" of
classified projects anyway (not really!) You can't restrict which
classes or packages come over between project dependencies in
Eclipse, if that project is referenced, so enforcing this negative
classpath is actually just creating a situation where you have to
configure something manually just to create a slightly less broken
scenario that you can't ever get perfect anyway. (Unless, I suppose,
you removed the project dependency altogether, and added classes
back, folder-by-folder, which I doubt most people would ever do, and
in the extremely specialized case where they would need to, then
that person would already know how and would go do it.)
On Tue, May 21, 2013 at 12:17 PM, Lincoln Baxter, III
<lincolnbaxter@xxxxxxxxx <mailto:lincolnbaxter@xxxxxxxxx>> wrote:
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?
~Lincoln
On Tue, May 21, 2013 at 11:37 AM, <ggastald@xxxxxxxxxx
<mailto: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..
Thanks for taking a look!
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
--
*George Gastaldi* | /Senior Software Engineer/
JBoss Forge Team
Red Hat
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev
