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 <
[email protected]> wrote:
>
>
> Sent from my iPhone
>
> > On 15 Oct 2016, at 14:20, Stephen Connolly <stephen.alan.connolly@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
>
