Stephen, One more slightly more abstract comment.
Your design document seems like a survey of current maven design. I think it should be better to present several 3-4 current main pain points and/or much desired features at first and then show how each and every design alteration provides for achieving specified goals... -- Victor Nazarov On Mon, Dec 5, 2016 at 7:22 PM, Victor Nazarov <[email protected]> wrote: > 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 >> > > >> > >> > >
