Not having read all of this for now, but that's what I was referring to
with "relaxing a constraint is easier than enforcing a new one". When in
doubt how to process conflicting elements or something like that, just
error out and fail the build with a descriptive error message. If we
later find out about such a constraint making a valid use-case
impossible, we can relax that easily.
Am 05.12.2016 um 01:31 schrieb Hilco Wijbenga:
> On 4 December 2016 at 14:56, Stephen Connolly
> <stephen.alan.conno...@gmail.com> wrote:
>> I'm currently trying to figure out how to make mixins possible in POM 5.
>
> This is wonderful news!
>
>> Mixins basically bring a form of multiple inheritance to the POM... which
>> leads to the problems of how to solve conflicts.
>
> Why allow both inheritance and mixins? Why not simply allow only one
> or the other? Or rather, allow inheritance only until mixins enter the
> picture. So you could have a grandparent POM (without mixins), a
> parent POM (without mixins), and then a child POM (potentially with
> mixins). I don't really see the value in inheritance if mixins are
> available. (But I can see why it would be nice to try and re-use an
> existing company POM or similar.)
>
> That still leaves the problem of including contradicting mixins. I
> would simply disallow any contradictions. Keep it as simple as
> possible, you can always make it more complex later. It is already
> going to be quite difficult to clearly explain any encountered
> problems to the user without any additional complexity.
>
> Some more thoughts:
>
> 1. Mixin A says <element>A</element> but Mixin B says
> <element>B</element>. Maven should disallow that. The solution for
> this would be to reference a property. Then both A and B could simply
> state <element>${element.value}</element>. Obviously, this may clash
> (there may have been a very good reason for requiring "A" or "B") but
> it is now up to the user to set ${element.value} appropriately or
> change the combination of mixins. I don't see how Maven would be able
> to resolve this.
>
> 2. Mixin A says <elements><a/><b/></elements> but Mixin B says
> <elements><b/><a/></elements>. Again, this should not be allowed.
> Maven can't possibly tell whether the order is relevant.
>
> I have been thinking of a tool to do exactly this. It would use mixins
> to generate the entire POM. With the above restrictions it seems
> possible to achieve a real "define it once" type of build. Obviously,
> it would be much nicer if Maven simply supported this natively. :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
