Just thinking about how different repositories can be handled. I think we should at least track the "origin" repository ids an artifact has been resolved from to have something to match against the effective repositories of a project. So that an artifact resolved from a repository not part of a consuming project can be discarded. It may not be available for download for that project. The causing issue is the lack of artifactId or groupId authority. So as long as the coordinates cannot be used to map to a set of authoritative repositories, this information needs to be tracked somehow.
Am 09/26/16 um 15:29 schrieb Stephen Connolly: > 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]
