Am 26.09.2016 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="..."]>
groupId, artifactId and version are the ones specified at <project> level, correct? > <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 Version can be optional when lack of it has a specified meaning. No version means all versions, for example. Version range needs to be optional for when they haven't been used, I think. > --> > <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 --> Is that nesting intentional? > <provides groupId="..." artifactId="..." [platformId="..."] > version="..." [range="..."] type="..." [classifier="..."]> > ... > </provides> Is the following <requires> intentional or should that read <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]
