I haven't been following your proposals. I have schemed through just now. I can say that I generally like some aspects of your proposal:
* build/artifact description split is a good thing. * custom lifecycle declaration is great. * building and reporting rejoin seems right I've fails to fully comprehend the idea behind inline template declarations. As I understand you what to provide a way to replace parant's or mixin's template with another. But I fail to see any motivation behind this decision. Another aspect that seems questionable is custom scopes... I've been using ivy-based build system recently and I think custom scopes don't pull their weight. I think there are very few use-cases for scopes other than maven's current scopes... What I'd like to contribute is that in my opinion templates should be defined by mojo's or plexus-components the same way plugins are defined and templates should have custom configuration. That way a company can define a FAMILY of lifecycles and a choice of one particular lifecycle depends on a specially crafted human readable configuration. Having configurable templates in place I think we don't need mixin's anymore... -- Victor Nazarov On Mon, Dec 5, 2016 at 6:38 PM, Stephen Connolly < [email protected]> wrote: > Victor, have you been following my designs? > https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0 > https://cwiki.apache.org/confluence/display/MAVEN/ > Project+Dependency+Trees+schema > and > https://cwiki.apache.org/confluence/display/MAVEN/Remote+repository+layout > ? > > On 5 December 2016 at 15:28, Victor Nazarov <[email protected]> > wrote: > > > I've been experimenting with profile-based system that is close to mixins > > [1]. > > Another existing maven extension for this is maven-tiles [2]. > > I think your design is close to maven-tiles, so you can try to survey > it's > > developers to > > get feedback based on actual usage... > > > > Personally after my experiments with these systems I've come to a > > conclusion > > that mixins is wrong direction. > > I envision that the best solution to all my use-cases is configurable > > lifecycle/lifecycle-mapping [3]. > > Configurable lifecycle should be like a collection of mixins defined in > > single module and thus guaranteed > > to work seamlessly with each-other. Mixin selection/activation mechanism > > should also be defined in > > configurable-lifecycle component and can be made as ergonomic as needed > > using custom configuration > > same way configuration is used by mojos. > > > > [1] > > https://github.com/sviperll/ozymandias/tree/master/maven- > > profiledep-extension > > [2] https://github.com/repaint-io/maven-tiles > > [3] https://issues.apache.org/jira/browse/MNG-6129 > > > > -- > > Victor Nazarov > > > > On Mon, Dec 5, 2016 at 1:56 AM, Stephen Connolly < > > [email protected]> wrote: > > > > > I'm currently trying to figure out how to make mixins possible in POM > 5. > > > > > > Mixins basically bring a form of multiple inheritance to the POM... > which > > > leads to the problems of how to solve conflicts. > > > > > > Inheritance Style > > > ============= > > > > > > The first problem I hit was how to actually deal with a parent that > > > declares some mixins and a child that declares other mixins where those > > > mixins declare some of the same mixins from the parent but different > > > versions... yes a some what esoteric edge case... but we can rest > assured > > > that users will hit this. > > > > > > I see two solutions to that problem: > > > > > > Option A: each project is consumed as its effective-pom (i.e. the > mixins > > > are merged before we consider application) > > > Option B: each project is treated as a graph of its mixins, then to > apply > > > inheritance we do conflict resolution on the versions, pick the > "nearest" > > > version, prune out the subtrees of the "loser" versions and away we go. > > > > > > Option B feels like the more "correct" option... but heck I cannot even > > > describe it well so how on earth are users to understand it. > > > > > > Thus, in the interests of simplifying life for users I am proceeding > with > > > the Option A approach... if that means that your parent has declared > the > > > myfaces-app:2.3 mixin and the child declares a tomee-web:3.0 mixin and > > that > > > mixin happens to include myfaces-app:2.5 then the child pom will have > > both > > > the myfaces-app:2.3 and myfaces-app:2.5 mixins applied... which may > leave > > > some "junk" that was in the myfaces-app:2.3 but removed from > > > myfaces-app:2.5 present in the child pom... at least they can figure > out > > > where that "junk" is coming from and remove it from their own effective > > pom > > > or bump the parent. > > > > > > Thoughts? > > > > > > Inheritance Priority > > > ============== > > > > > > Mixins on their own are fine. Parents on their own are also fine... > when > > we > > > have the two, how do we decide who wins. > > > > > > My current thinking is that there would be some parts of the model that > > can > > > only come from the parent: informational stuff, deployment stuff. > > > > > > But that should be a very small part of the model. We want mixins to be > > > able to contribute to the rest of the model. > > > > > > And here's the rub, in my parent I define some default conventions for > > > plugins, dependencies, etc... we then want the mixins to be able to > bring > > > their best practices with them, so mixins need to be higher priority > than > > > the parent... but we also want the parent to be able to enforce some > > > things. > > > > > > So say I want my parent to enforce that we only use myfaces for JSF. I > > may > > > have dependency management for various other jars... then the child > > brings > > > in some mixin and that mixin is directing all the JSF jars to the RI > (not > > > because the mixin is focused on the RI, but because they wanted to > align > > on > > > one thing) > > > > > > If mixins happen before parent, then some of the key rules of the mixin > > > will be defeated. > > > If mixins happen after parent, then the parent cannot enforce policy. > > > > > > I believe the enforcement of organizational policies is an important > use > > > case for parent projects, but the quest for mixins that I have seen > from > > > the JIRA is about being able to pull in configuration that has been > > tested > > > and should supercede the organizational *defaults*. > > > > > > I think the solution to this is to give the parent a <policy> section > > > (which could only contain the elements permitted in a mixin) and have > the > > > inheritance priority be: > > > > > > 1. Start with the defaults for the current template (a.k.a packaging in > > > 4.0.0 speak) > > > 2. Apply the defaults from the parent pom > > > 3. Apply the template specific defaults from the parent pom > > > 4. Apply each mixin in turn (global first, then template specific) > > > 5. Apply the project itself configuration > > > 6. Apply the parent policy. > > > > > > I think that the parent policy should be inherited from its parents but > > > whatever is said in the parent policy can override what is said in the > > > grandparent. > > > > > > Thoughts? > > > > > > Thanks for your consideration > > > > > > -Stephen > > > > > >
