So building the effective build time model would be: Start with parent, add in matching packaging from parent, in Pom order, add each mix-in (including matching packaging from mix-in before processing subsequent mix-ins), finally apply local pom.
To compute effective lifecycle and build plan, allow platform activation to be considered... each platform is like a mini-sub project that can "run in parallel" (yes I need to doc this better...) 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 >
