On Wednesday 31 August 2016, Christian Schulte <[email protected]> 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
>
> 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: [email protected] <javascript:;>
> For additional commands, e-mail: [email protected] <javascript:;>
>
>
--
Sent from my phone
