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;

}

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
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to