On Sat, 16 Jul 2016 20:15:16 +0200, Christian Schulte <[email protected]>
wrote:
Am 16.07.2016 um 15:40 schrieb Robert Scholte:
I understand that every element has an original scope, but I wonder if
it
is useful in the tree. I'd say based on the scope(s) you get a certain
tree, where scopes don't matter anymore.
This would probably also solve the test-scoped issue in the other
thread.
project () // no scope filtering
+- a
| \- c:1
| \- x
\- b
project (runtime,compile)
+- a
| \- c:1
| \- x
\- b
project (runtime)
+- a
| \- c:1
| \- x
project (compile)
+- b
\- c:2
\- y
So you would also say that the nodes should be choosen based on the
context of the root node? If you depend on something in compile scope,
that scope should have priority when selecting nodes no matter the depth
of conflicting nodes. Same for the other scopes. If you depend on
something in test scope, that scope should have priority when selecting
nodes no matter the depth of conflicting nodes etc. This is what I am
working on locally. Still work in progess. Still need to carefully
review all those ITs and also implement version ranges to have something
to talk about.
Regards,
Quite close. I don't think there's something like priority for scopes. The
first thing that should be done is select all dependencies based on the
specified scopes. So e.g. maven-compiler-plugin:compile would specify the
scopes compile, provided and system. After filtering out all unnecessary
dependencies the nearest-rule kicks in again.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
