I'm thinking that we still want a dependency management section, so I'd probably just have that as a dependency tag at the top level or aggregate them in a dependencies tag at the top level... mostly that section though becomes about specifying versions... and really it's only useful from the parent pom... and I wonder if the supports concept in the PDT will remove the need...
Needs thinking either way Sent from my iPhone > On 15 Oct 2016, at 15:26, Stephen Connolly <stephen.alan.conno...@gmail.com> > wrote: > > Thinking out loud... perhaps something like > > <project modelVersion="5.0.0" [groupId="..."] artifactId="..." > [version="..."] packaging="..."> > [<parent groupId="..." artifactId="..." [version="..."] > [relativePath="...']/> > > [<mixin groupId="..." artifactId="..." [version="..."]/>] > [<mixin groupId="..." artifactId="..." [version="..."]/>] > ... > [<mixin groupId="..." artifactId="..." [version="..."]/>] > > [<lifecycle id="..." mode="override|inherit"> > <phase id="..." [after="..." | before="..."]/> > <phase id="..." [after="..." | before="..."]/> > ... > <phase id="..." [after="..." | before="..."]/> > </lifecycle>] > [<lifecycle id="..."> > ... > </lifecycle>] > ... > [<lifecycle id="..."> > ... > </lifecycle>] > > [<scope id="compile" [mode="override|inherit"]> > <dependency groupId="..." artifactId="..." [platformId="..."] > version="..." [classifier="..."] type="..."/> <!-- type is mandatory--> > <dependency groupId="..." artifactId="..." [platformId="..."] > version="..." [classifier="..."] type="..."/> > ... > <dependency groupId="..." artifactId="..." [platformId="..."] > version="..." [classifier="..."] type="..."/> > </scope>] > [<scope id="..."> > ... > </scope>] > ... > [<scope id="..."> > ... > </scope>] > > [<plugins [mode="override|inherit"]> > <!-- this is what pluginManagement was --> > </plugins>] > > [<bindings [mode="override|inherit"]> > <!-- this is what plugins was, we make explicit here that this is the > binding of executions into the lifecycles --> > </bindings>] > > [<platform id="..." [mode="override|inherit"]> > <activation> > <!-- define how we determine that this platform can be built in the > current environment --> > </activation> > <!-- allow platform specific mixins --> > [<mixin groupId="..." artifactId="..." [version="..."]/>] > <!-- allow platform specific lifecycles --> > [<lifecycle id="..."> > ... > </lifecycle>] > <!-- allow platform specific dependencies --> > [<scope> > ... > </scope>] > <!-- allow platform specific bindings... but plugin management is from > the root only --> > [<bindings> > ... > </bindings>] > > <!-- allow most of the other root tags except platform and packaging and > deployment config --> > </platform>] > [<platform id="..."> > ... > </platform>] > ... > [<platform id="..."> > ... > </platform>] > > <!-- packaging is only allowed in poms with an id of "parent" or "mixin". > It allows a parent/mixin to be used by different packaging ids and define > specialized defaults --> > [<packaging id="..."> > [<mixin groupId="..." artifactId="..." [version="..."]/>] > <!-- allow platform specific lifecycles --> > [<lifecycle id="..."> > ... > </lifecycle>] > <!-- allow platform specific dependencies --> > [<scope> > ... > </scope>] > <!-- allow platform specific bindings... but plugin management is from > the root only --> > [<bindings> > ... > </bindings>] > <!-- allow most of the other root tags except platform and packaging and > deployment config --> > </packaging>] > [<packaging id="..."> > ... > </packaging>] > ... > [<packaging id="..."> > ... > </packaging>] > > <!-- unsure if we still need profiles --> > <!-- perhaps we still need properties --> > <!-- TBD deployment config, repositories, etc --> > > </project> > > > Most of the above is just a note for myself based on thoughts I had while > going for a walk... but it may inspire others to think about this topic too > > -Stephen > > >> On 15 October 2016 at 14:34, Stephen Connolly >> <stephen.alan.conno...@gmail.com> wrote: >> >> >> Sent from my iPhone >> >> > On 15 Oct 2016, at 14:20, Stephen Connolly >> > <stephen.alan.conno...@gmail.com> wrote: >> > >> > So now that I have a spec for the PDTs drafted, I have been thinking of >> > how that could influence Maven 5. Some things that came to mind, in no >> > particular order: >> > >> > * scope becomes a build time only concern. Thus we can let users define >> > custom scopes in their pom. If we let plugin executions declare scopes to >> > resolve, we no longer need a compiler:testCompile goal as you can just >> > have a second default execution of compiler:compile with different >> > required scopes and different default configuration... bonus win, I can >> > now add many different layers of test-compilation for integration tests, >> > etc... each pulling in different scopes... ditto for surefire/failsafe... >> > yeah integration tests >> > >> > * we should let the user define lifecycles directly in the Pom (ok, maybe >> > we don't *encourage it*) >> > >> > * mixins can be properly considered... they only affect build time anyway >> >> Mixins should get their own packaging type >> >> > >> > * Pom doesn't need to be XML any more... (maybe we want to keep XML >> > though... just a less verbose form) >> > >> > * does Maven 5 build Maven 2/3 projects? >> >> We may want to keep XML but move to attributes... in which case it would be >> super awesome if Maven 3.4.x didn't see project/modelVersion then it should >> check for same as attribute and then say: you need a newer Maven to >> build/inherit this >> >> > >> > Sent from my iPhone >
