Besides adding the original repository somewhere I would like to add the
file-extension.
Now you are required to translate the type to the extension based on the
ArtifactHandler, which is a waste of time in this case. During build it is
indeed good to use packaging, so you can control the plugins for its
lifecycle, even when they result in files with same extensions (e.g. jar
and maven-plugin). A dependency-type is kind of weird, I haven't figured
out yet why not just using the extension. As if you would control some
kind of filtering, which should be done with the scope.
There's also a request to have the ability to add some kind of signature
to the dependency to ensure the project is using the correct artifact and
not some patched one. Https already saved us from the man-in-the-middle
attack, but doesn't prevent us from this kind of hacking.
Assuming you will only specify runtime required dependencies here, I think
the flex-team had the requirement for different scopes of jar files both
required at runtime. Will need to go through the archive for this.
thanks,
Robert
On Mon, 26 Sep 2016 15:29:06 +0200, Stephen Connolly
<[email protected]> wrote:
Here's an approximation of my current thinking:
<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>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
