So I am seeing conflicting requirements and I am unsure how we should approach resolving them:
1. Seems perfectly reasonable to add some form of integrity details about the *project's artifacts* into the PDT. Probably a SHA512 hash... 2. We could probably add the SHA512 hashes of dependencies... we know what the resolved version was when the PDT was generated and we know the hash that was used... may lead to conflicting hashes for the same artifact at different points in the tree... may lead to issues if specific artifacts get regenerated (for example if I use staging, I may stage foo:1.2 you then stage bar:2.5 depending on foo:1.2... then somebody finds a bug (was compiled with wrong jdk, so we drop the foo staging repo and respond foo:1.2 from the tag)... now if we promote bar:2.5 it will never find the foo:1.2 with a matching hash. 3. Alternatively we could add the gpg keys that the artifacts were signed with... hmm similar set of issues there... Basically, other than my project's artifacts and enforcing that they have been signed by the project key... seems hard to square "don't let somebody MiM my transitive dependency" with "what if the worst happens and we have to rebuild from tags and sign with anew key". You could argue that "the worst won't happen"... ok while central is the central point, that's exceeding unlikely given the redundant copies with more than one organisation... but a goal we have is to allow decentralised central... so that say junit could choose to host their own artifacts as the canonical repo that everyone would "discover"... as soon as we open that door, we let all the projects have the headache of looking after their DR... So, if we want to allow a decentralised central then I think we need some way to handle "recovered" artifacts from SCM tags. Similarly I think the origin repo might be kept out of the PDT and managed by the consumer... but that's a lesser concern for me at present On Wednesday 28 September 2016, Robert Scholte <[email protected]> wrote: > 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] > > -- Sent from my phone
