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.
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
>
>
--
Sent from my phone
