On Monday 26 September 2016, Christian Schulte <[email protected]> wrote:

> 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?


Yes as these are the artifacts of the project


>
> >             <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.


I just need to think the spec of this through... it was more a note to self
and hint to others that I'm not finalised on this point


>
> >             -->
> >             <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?


Yes, it is the whole tree so that consumers don't need to resolve any more
trees (unless you are deviating on versions), you only need to process the
tree to compute the effective depent artifacts for resolution


> >                 <provides groupId="..." artifactId="..."
> [platformId="..."]
> > version="..." [range="..."] type="..." [classifier="..."]>
> >                     ...
> >                 </provides>
>
> Is the following <requires> intentional or should that read <provides>?


This is a good question.

My intent is that you can have requires as a tree... but thinking more,
perhaps we can treat this like supports and say that the requires should be
promoted up as this has been "rebundled"... needs thinking


>
> >                 <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] <javascript:;>
> For additional commands, e-mail: [email protected] <javascript:;>
>
>

-- 
Sent from my phone

Reply via email to