On Wed, 31 Aug 2016 22:51:20 +0200, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
On Wednesday 31 August 2016, Robert Scholte <rfscho...@apache.org> wrote:
On Wed, 31 Aug 2016 19:35:02 +0200, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
On Wednesday 31 August 2016, Christian Schulte <c...@schulte.it> wrote:
Am 08/31/16 um 18:39 schrieb Christian Schulte:
> Am 08/31/16 um 07:52 schrieb Stephen Connolly:
>> I've been thinking about what to call the "consumer Pom"...
>>
>> I think this is actually not a project object model, but the
project
>> dependency trees
>>
>> It should list each side artifact and their dependency trees...
>>
>> So for example:
>>
>> * the java doc artifacts should depend on the corresponding
dependency
java
>> doc artifacts (in an ideal world) because we expect {@link}
references
>>
>> * the source artifacts do not depend on anything else (normally)
but
for an
>> über jar (which yes is a bad pattern) you would actually be
correct to
>> depend on the bundled artifacts source jars... So the concept still
makes
>> sense
>>
>> * the test jar artifact would have the full test dependency tree
exposed as
>> this would allow for test reuse
>
> +1
>
> Sounds like dependency trees by scope. The compile scope tree, the
> runtime scope tree, the test scope tree, the documentation scope
tree,
> the source code scope tree, the invented by a 3rd party scope tree,
etc.
>
public interface DependencyTreeProvider
{
DependencyNode getDependencyTree( String logicalScopeName )
throws IOException;
}
Not `String logicalScopeName` but `Artifact artifact`
Because... Otherwise we have to pick a defined list of scope names and
their meaning... Any defined list of scope names will be different...
So
better is to just publish the one tree per artifact
Exposing the logical scope is a mistake IMHO
There is one gotcha though... Sometimes you need a transitive
dependency
to
compile but do not need it at runtime... How to handle that needs some
thought... But right now it is a problem anyway, and it is probably
safer
to just force it onto the "effective" tree and let the consumer who
*knows
they don't really need it* strip it from their tree (at the final
point of
use... Because it would also need to be on their compile path)
I think the original view we had with maven where compile scope would
not
be transitive is no longer compatible with JavaC and basically compile
scope will always need to be transitive.
So I am -1 on exposing details like "scope" to consumers
We do need to expose "optional" so the consumer can resolve version
conflicts with the optional dependency
HTH
I agree that scope is something to filter on, it should not be part of
the
resolution result.
The challenge I see is to select the proper artifact in case of multiple
scopes.
For example: the compiler:compile wants all dependencies with the scopes
'compile', 'provided' (and 'system'). if the same GA has different
versions
per scope it must be clear which one to choose.
I hope we can resolve this without "nearest wins" strategy, the answer
should somehow be in the .pdt;
Well I am not seeing a case for *consumers* to need different trees for
the
same artifact.
I had a discussion with Christian Schulte about this[1][2].
Going for nearest doesn't always give a rational result. I think you
should first go for the scope, next for nearest.
Somehow such questions must be answered in the .pdt
Robert
[1] http://maven.markmail.org/thread/qkudtbkiru4yynpl
[2] https://issues.apache.org/jira/browse/MNG-4800
The only case I can imagine is our *old* vision for compile scope... But
I
think that need can be handled by optional in the worst case... My
preference is to let the consumer of the dependency remove the bits they
don't want...
In essence each jar artifact's dependency tree would be that artifacts
effective runtime tree.
So for the tests-jar.., that would have a declared dependency on the
regular .jar and provide the tree for the test-runtime scope... It may
even
be that there are therefore closer overrides of the main artifact's
dependencies in the test jar's tree... That should all be fine.
If you are compiling against the dependency and want to use a different
version of the dependencies then you *as consumer* can override the tree
by
configuration... I think that is the best compromise.
Robert
The implementation of that method is broken down to just
reading/parsing
an XML file that way. You can implement that easily with every
programming language of interest. There is no scope logic to
implement.
That's done at build time.
When all those different trees have been fetched, the 'only' thing
left
to implement is conflict resolution / building the effective
dependency
tree. Since scopes have already been resolved, that could possibly
also
be broken down to just one very simple rule: nearest wins - no
exceptions. Version ranges are only there to be able to check for
conflicting ranges or hard requirements, right?
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
<javascript:;>
For additional commands, e-mail: dev-h...@maven.apache.org
<javascript:;>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
