[SUREFIRE-2179] Support adding additional Maven dependencies to the test runtime classpath

[kwin]

No description provided.

[slawekjaranowski]

An integration test will be appreciated for such feature.

[olamy]

is it possible to have an IT test? as I cannot see any test here. thanks

[kwin]

is it possible to have an IT test? as I cannot see any test here. thanks

Done now, you find it in https://github.com/apache/maven-surefire/pull/667/files#diff-311598b970ad59d912704889726abb7abbf6d92d3d5382a94d85c8c686ab24b9R21

[cstamas]

For all non POM/dependency and POM/plugins/plugin/dependency elements, especially for plugin config like this one (or like compiler anno processor is, etc) we MUST BE CLEAR that it works ONLY for external dependencies. These elements do NOT participate in project topological sorting, hence, becomes impossible to use some reactor project for these (without hacks). Moreover, if using reactor artifacts, this is one of the reasons why users are forced to to mvn install as 1st pass, and from 2nd pass onward "it will work", but again, what is being used "lags" one build cycle (as installed thing is being used, not the currently built one).

See for example here https://issues.apache.org/jira/browse/MNG-6877

[cstamas]

In fact, IMHO we should revisit ALL these plugins having "artifact-like" (GAV) parameters and using resolver to resolve them, and

• mark all these configurations as "usable for out-of-reactor artifacts only" (or, be very clear that it is user who needs to hack in proper build order by whatever means he can)
• or come up with some proper solution in Maven to make sorting aware of ALL these

Biggest problem with parameters like this is when using in-reactor artifact, "by chance" the ordering may be good, and seemingly everything works, but then user changes something completely unrelated (ie. adds a new module to build), that changes build order, and suddenly this breaks. In this situations is hard to figure out why breakage happened.