I am toying with having the format be xml.gz rather than xml JavaScript, Rubies, .NET and the JRE all have portable implementations so would seem reasonable given the high repeats in the content.
OTOH transport GZ should be easy and makes the file easier for users to inspect Thought? On Monday 26 September 2016, 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> > -- Sent from my phone
