"The only difference between a parent project and a mixin is that the mixin is abstract (not a complete model)."
Is that really true? A Mixin should be deployed to the repository, which essentially means it needs to be complete enough to id and thus a complete model. It should be deployed as a classified artifact though to avoid mixing in the instructions for building/deploying from those that are intended to be mixed in. (ie the mixin's pom is separate) 3.1: what about multiple parents? I assume it's the first one, but should be explicit in the spec. 3.2: section is blank but contentious based on current behavior and the in-ability to use properties and inheritance together. 3.3: I don't understand this statement. A child always overrides the parent or joins with it. Are you saying that the parent wins here? Also pluginRepositories is going away soon. In general why can't the things listed here be extended? 3.4 shouldn't project.distMgt.relocation be inherited if the relocation lists the group? (group/artifact/version ones should be skipped, but if you're relocating everything in a group, it would make sense to do this at the top of that group tree pom) 3.5 I agree with Ralph here that Final is the wrong term. Private is more appropriate. I started this in the morning and didn't finish yet so sending what I have. -----Original Message----- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Tuesday, December 16, 2008 3:59 AM To: Maven Developers List Subject: Re: POM construction specification On Dec 15, 2008, at 12:02 PM, Jason van Zyl wrote: > This is for the general population but I'm nudging you Ralph because > I know that you want to make some changes for not requiring the > version in the parent element. > You should have warned me to have a glass of wine before attempting to read all these math notations. :-) Or put a link to http://en.wikipedia.org/wiki/Table_of_mathematical_symbols for those of use who haven't had a math class in the last 25 years. The funny thing is, I have a B.S. in Physics. Man it has been a long time. :-( Comments: 1.1 Mentions there are 465 model properties. An appendix should list them. Specifically, I'd like to see "provides" listed along with the project's groupId, artifactId and version and "requires" in the dependency declaration - or whatever other way that kind of metadata will be added. 2.1 & 2.2 Is all this simply stating that the closest definition wins and when two or more are equally close then the first one wins? 2.4 The only "definition" of mixin is "The only difference between a parent pro ject and a mixin is that the mixin is abstract (not a complete model)". That sure leaves a lot to the imagination. And what exactly makes a model "incomplete"? Isn't a pom with just a dependencyManagement complete? I also found myself wondering that even though it might be possible to support extending multiple parents, should we? I could see allowing only one parent but multiple mixins. 3.1 Even though may be obvious, it should explicitly state that artifactId is always required. 3.4 Why can't the groupId be inherited from its parent (or at least be set from project.parent.groupIdt)? 3.4 The footnote says the artifactId can be inherited from the parent. That makes no sense to me. Every pom should represent a unique artifact or at least a unique pom. 3.5 I found the statement This will mark the container as final, thus preventing inheritance:" as misleading. In java terms this would mean a child pom attempting to define the same plugin would fail. The setting of "inherited" to false in the sample indicates to me the opposite, the plugin definition in the parent is invisible to the child. Here is a question though. If A overrides a plugin defined in the super pom and has inherited true, then B extends A and overrides the plugin and sets inherited to false, what will C which extends from B get? It should see the definition in A. Or does this whole section mean that the plugin definition in B inherits nothing from A? 3.8 "the element will be inherited." Unless the parent definition has <inherited>false</inherited> ? I don't see anything in here about being able to locate a parent without having to know its version. Within the scope of the purpose of this document it may not be relevant, but at the very least somewhere in section 3 it should state that if a parent is specified than which elements are required. I hope this was the kind of feedback you were looking for. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
