Status
This RFC is currently in the DRAFT state. Nothing in this RFC has been agreed or confirmed.
Contents
Introduction
The Project Dependency Trees artifact defines all the side artifacts of a project as well as each artifacts tree of dependencies. This can be used by consumers to decide what the consumers effective tree of dependencies is as well as allowing consumers to perform intelligent substitutions in the tree. By providing the entire tree we can reduce the number of requests a consumer needs to make in order to resolve all the artifacts the consumer requires.
TODO write the content and formalise the following example into a schema:
<project modelVersion="..." groupId="..." artifactId="..." version="...">
<information>
<!-- container for descriptive information -->
[<name>...</name>]
[<description>...</description>]
...
</information>
<artifacts>
<artifact [platformId="..."] type="..." [classifier="..."]>
<information>
<!-- override root level information for specific artifacts -->
</information>
<!--
components are internal packaging constructs used by the packaging type but requiring more general validation
e.g. for Java 9+ the ids could be the module ids if we wanted to validate that the module ids were unique in the
effective tree.
-->
<component id="..."/>
<component id="..."/>
...
<component id="..."/>
<!--
licensing is a top level concern, and legitimately can vary per artifact. Let's not solve license compatibility,
rather leverage https://spdx.org/
-->
<license spdx:id="..."/>
<license spdx:id="..."/>
...
<license spdx:id="..."/>
<!--
provides is a marker that we have duplication of content. This could be because we are much like the many servlet-api jar
files where there are many GAV's of the same javax.servlet:servlet-api:3.0 thus we could have the case where
org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar:1.0.2.Final PROVIDES javax.servlet:servlet-api:3.0
org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar:1.0.1.Final PROVIDES javax.servlet:servlet-api:3.0
org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar:1.0.0.Final PROVIDES javax.servlet:servlet-api:3.0
org.mortbay.jetty:servlet-api-3.0:jar:7.0.0pre2 PROVIDES javax.servlet:servlet-api:3.0
similarly
org.slf4j:log4j-over-slf4j:jar:1.7.21 PROVIDES log4j:log4j:[1.0,2)
The consumer of the tree can then decide if/when/how to collapse redundant nodes as they see fit.
TODO: decide optionality of version and range attributes
-->
<provides groupId="..." artifactId="..." [platformId="..."] version="..." [range="..."] type="..." [classifier="..."]>
<!-- no component here as we have "rebundled" hence implicitly promoted up one level-->
<!-- no license here as we have "rebundled" hence implicitly promoted up one level -->
<provides groupId="..." artifactId="..." [platformId="..."] version="..." [range="..."] type="..." [classifier="..."]>
...
</provides>
<requires groupId="..." artifactId="..." [platformId="..."] version="..." [range="..."] type="..." [classifier="..."]>
...
</requires>
<!-- no supports here as we have "rebundled" hence implicitly promoted up one level -->
...
</provides>
<provides groupId="..." artifactId="..." [platformId="..."] version="..." [range="..."] type="..." [classifier="..."]>
...
</provides>
...
<provides groupId="..." artifactId="..." [platformId="..."] version="..." [range="..."] type="..." [classifier="..."]>
...
</provides>
<!--
requires are the mandatory dependencies. This is effectively a recursive artifact where the GAV is not inherited and
where we have discarded the information section. If you want those details, fetch that project's dependencies trees.
-->
<requires groupId="..." artifactId="..." [platformId="..."] version="..." range="..." type="..." [classifier="..."]>
<component id="..."/>
<license spdx:id="..."/>
<provides groupId="..." artifactId="..." [platformId="..."] version="..." [range="..."] type="..." [classifier="..."]>
...
</provides>
<requires groupId="..." artifactId="..." [platformId="..."] version="..." range="..." type="..." [classifier="..."]>
...
</requires>
<supports groupId="..." artifactId="..." [platformId="..."] version="..." [range="..."] type="..." [classifier="..."]/>
</requires>
<requires groupId="..." artifactId="..." [platformId="..."] version="..." range="..." type="..." [classifier="..."]>
...
</requires>
...
<requires groupId="..." artifactId="..." [platformId="..."] version="..." range="..." type="..." [classifier="..."]>
...
</requires>
<!--
supports are the optional dependencies. We list them here to aid in conflict resolution. We do not include a nested tree
as a consumer would only pull them in if the consumer already has its own a requires for them, so we really only
need to validate the range.
TODO: decide optionality of range attribute
TODO: decide if we want a version attribute
-->
<supports groupId="..." artifactId="..." [platformId="..."] version="..." [range="..."] type="..." [classifier="..."]/>
<supports groupId="..." artifactId="..." [platformId="..."] version="..." [range="..."] type="..." [classifier="..."]/>
<supports groupId="..." artifactId="..." [platformId="..."] version="..." [range="..."] type="..." [classifier="..."]/>
</artifact>
<artifact ...>
...
</artifact>
...
<artifact ...>
...
</artifact>
</artifacts>
</project>