On Mon, 26 Dec 2016 17:07:14 +0100, Christian Schulte <[email protected]>
wrote:
Am 12/26/16 um 11:36 schrieb Robert Scholte:
This is becoming a bug versus feature discussion.
It shouldn't.
Up until now you've made
changes which might change the resolution because you've marked them as
a
bug which must be fixed. However, what is 'the truth': the documentation
or the code? The answer is: in the end it is the code. And if you want
to
have them in sync, you sometimes need to adjust the documentation
instead
of the code, because the code has a behavior one is used to.
Have you read the Javadoc and the code? If you would have done that, you
would notice that everything behaves consistently and as documented
*but* one class which is fixed now. If it would be *all* classes, there
would be no question the code is behaving the way it should.
MRESOLVER-8
This *only* affects plugin and extension resolution by stopping to
discard any test and provided *direct* dependencies of a plugin the same
way optional *direct* dependencies are not discarded and the same way
the dependency manager is not managing *direct* dependencies. It does
not affect project resolution in any way. That's what we are really
lucky about. If we don't want Maven to behave that way (with plugin and
extension resolution fixed) it's the Maven codebase to adjust - not the
resolver. That's just an API used by Maven and should just be consistent
and correct. The original author really could have left a few unit tests
in that area. We would not discuss anything, if he would have done that.
He would have noticed things himself or would have left a comment at
least. The issue above together with
MRESOLVER-9
MRESOLVER-10
is really "just" bugfixes. What we learn from that is that we should
"commit" any resolution result during deployment so that bugs like these
can be fixed without influencing the resolution performed for a deployed
project. That's the PDT file we are going to deploy in Maven X.
Since we're talking about changes in resolution, I also expose this
topic.
To me it is not a bug nor a feature, but it is a design flaw. And the
issue is often not exposed, because the dependencies used for testing
are
not conflicting the compile dependencies. As long as the compilations
works and all the tests run, users often don't look in detail at the
dependency.
The fact right now is that if I add/change a test-scoped dependency, it
could happen that the project won't run due to a missing transitive
dependency.
We are very, very lucky this doesn't happen that often.
This is what would stop if we would just fix those bugs. We are running
into those bugs ourselves. Take a look at the PMD plugin POM again. What
would you have done, if the test dependencies I moved to compile scope
would be required for compilation of that project?
With the current behavior I wouldn't include these dependencies at all,
since they're already available as compile-scoped transitive dependency.
When due to an upgrade of a dependency commons-io is not used anymore,
tests will fail to compile. And that's the moment to add this dependency.
IMO changing dependencies should never cause compilation failures caused
by transitive dependencies, but right now there's simply no better
solution. We say that it is a best practice to always define the direct
dependencies, but in this case we can't do that because we cannot give
these dependencies the test-scope.
This is already
yelling for an enforcer rule or something like that. "Are all classes
used by the classes on the compilation classpath available during
compilation?" Currently it's a result of trial and error. Really. If we
let this go on, we need to be even more lucky in a few years. If we say
plugins and extensions just are not resolved the same way as projects
(how it has been for a long time), this will make the following IT start
to fail, when done consistently.
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=4d9d7104d3491ec4a00e3ffc6713d983c84a19d0>
So we would need to adjust the Maven codebase to keep it behaving as
before. The resolver is not the correct codebase for this. I could do
that easily although it's inconcistent with itself that way. If you take
a look at what updates needed to be performed to various plugin POMs,
those are really all bugs in the POMs. Either we fix them, or we make
plugin resolution differ from project resolution (non-transitive
*direct* dependencies only override main scope dependencies during
building but are ignored when building the runtime classpath). Just say
so and it'll be done. My personal opinion is that having a different
runtime classpath than what was used during building is a bad idea and
we are running into issues due to this ourselves which proves this
correct.
I agree that compile and runtime classpath should be the same (apart from
provided/runtime scoped deps of course). Just like test-compile and test
(which is actually the runtime with the test-classpath).
Between these sets there can be differences for good reasons.
IMO scopes weren't designed to make transitive dependencies disappear.
And the way I'm describing it, the result will be that both compile and
runtime classpath can have extra artifacts, so with that in mind I don't
see the issue.
Robert
Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
