Am 10/15/16 um 16:26 schrieb Stephen Connolly:
> 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="..."]/>]
Looking at this from a syntax point of view only, we will run into those
"XML element declaration order has an implicit meaning" issues again.
Q: How are conflicts resolved?
A: There is no conflict resolution during building the effective model
(in general - not only for mixins). Mixin elements are just substituted
with what they reference in place - before inheritance processing. After
all mixins have been substituted, the effective model is validated. So
that it's perfectly valid to write redundant mixins like
<mixin groupId="G" artifactId="A" version="V"/>
<mixin groupId="G" artifactId="A" version="V"/>
leading to an invalid effective model that will not pass further
validation. Every identifiable complex content element should support
mixins. Maybe we name that element 'include' following XML schema. Maybe
allow selection of the node(s) to include based on XPapth.
<mixin groupId="G"
artifactId="A"
version="V"
[ xpath="project/lifecycle[id='whatever']" ]/>
Q: How to handle properties? What if someone writes:
<mixing groupId="${something.groupId}"
artifactId="${something.artifactId}"
version="${something.version}"/>
?
A: Current master dependency management import scope uses the effective
properties after inheritance processing. If mixins can bring in
properties, this is no longer possible because there is no way to build
the effective properties without substituting the properties of the
mixins. Current dependency management import does not have this issue
because it cannot import properties. So if properties can be brought in
via mixins, we cannot allow properties in mixins anymore. That's pretty
much the experience I gained by working on the import scope.
>
> [<lifecycle id="..." mode="override|inherit">
Maybe mode="override|append-parent|prepend-parent" or
mode="override|append|prepend" with "append" and "prepend" referencing
the element of the attribute. So that "prepend" equals "append-parent"
and "append" equals "prepend-parent". "prepend-parent"/"append" being
the default. More verbose: inheritance-mode. Also need "final" and
"override" boolean attributes working like the java keyword/annotation.
<lifecycle id="..."
[ mode="override|append|prepend" ] defaults to "append"
[ final="true" ] defaults to false
[ override="true" ] defaults to false>
> <phase id="..." [after="..." | before="..."]/>
> <phase id="..." [after="..." | before="..."]/>
> ...
> <phase id="..." [after="..." | before="..."]/>
"after" or "before" need to be mandatory to avoid order of XML element
declaration issues, if I got the intention of those attributes
correctly. As a general rule of thumb we should validate the model as
strictly as possible in the first release. It's easier to relax a
constraint in a next release then to enforce a new one. That's mainly
where all those warnings in Maven 3 come from. Cannot enforce a new
constraint, so print a warning. Let's try to do it the other way around
this time. Be as strict as possible. If something isn't quite clear,
just add a constraint disallowing the specific usage which can be
relaxed later.
That's mainly what came to mind when reading this the first time.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
