Dependencies and classloading errors during testing in XML-enabled projects

[Florin Vancea <fv...@maxiq.ro>]

(Please excuse me if this was already discussed before.)

There are (known) issues with testing projects that make use of the XML API.
AFAIK, currently the recommended way to overcome those is to fork the tests
(FAQ-ditto).
However, I "feel" that a possible solution would be to _exclude_ the
XML-related dependencies from classpath when running the tests and let them
to load through the higher classloaders, since Maven already uses them.
Of course, this is valid when using the same release in the project as the
one used by Maven itself, but I think this is a common situation. Even if
the versions are different, the API itself is rather stable, even in
implementation packages, and using a slightly different version is better
than ugly classloading problems.

Therefore I created a patch for my build environment that excludes selected
artifacts from the classpath used when _running_ the tests. The full
dependency CP is still used when compiling, both for the classes and for the
tests.

It works.

And this leads to the reason I'm writing this for:
A cool way (IMHO) to decide who is taking part in the primary compile, who
is taking part in test compile and who is there when running tests would be
to refine the information in <dependencies> section of the project.xml,
namely to explicitly specify that a particular dependency is needed for
compiling, for compiling tests, for running tests or for a combination of
those purposes.
I recall this has been discussed before, but I'd like to know which is the
projected direction the Maven team will take towards solving this range of
issues. This way I'll be able to direct my internal patches that way and
save some (painful) rewriting when Maven will include such features.

If you think my "solution" is worthy I can provide it to be included into
the evolving version.

Yours,
Florin

P.S. Yes, I noticed that the FAQ talks about 1.4 and I'm still using 1.3,
but I hope what I said is still relevant.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org