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;
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
