What problems are you trying to solve with mixins? What is missing from the current inheritance scheme?
It appears to me that you are putting the "how before the "what". My personal experience is that mixins lead to jar hell rather fast. Chas > On Dec 5, 2016, at 4:28 AM, Christian Schulte <[email protected]> wrote: > > 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 >> <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
