I think that may be problematic... but probably not the worst thing to add
to the schema (would just be an extra attribute)

Btw an alternative schema has a top level <platform> tag as a container for
the platform specific artifacts... has advantages with non-atomic deploys
of different artifacts as you can mandate such side-trees are single
platform only

On Tuesday 27 September 2016, Christian Schulte <[email protected]> wrote:

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

-- 
Sent from my phone

Reply via email to