Hmmm shower thinking now has me pondering if a custom DSL might be better... something close to human friendly JSON with exceptions for dependency declaration so that they are always specified as g:a:p:v:c:t with the optional p and c being empty, e.g. g:a::v::t
On 15 October 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 >> > >
