Comments in line On Tue, Dec 16, 2008 at 12:58 AM, Ralph Goers <ralph.go...@dslextreme.com>wrote:
> > 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: > 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.1 covers the high level processing starting with the transformation from the original model (XML) to the canonical model and going through interpolation and other rules. 2.2 does cover which property wins for: singletons, collections and sets. > 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. A mixin wouldn't be required to have things like project.version or project.groupId. This makes the model abstract. From the framework's perspective, it's all just a linear set of complete or incomplete models Whether it's considered multiple parents or a chains of inherited parents, it's all processed the same. My take is that if it's a complete model, it's actually just another parent. We are really just dealing with definitions here, it doesn't change processing. We can discuss more on what the definitions should be. > > 3.4 Why can't the groupId be inherited from its parent (or at least be set > from project.parent.groupIdt)? Technically, it isn't inherited from the parent. If groupId is not defined, the project.parent.groupId is used (footnote 1). > > 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. I'll change the spec doc. But when we throw in mixins, it's not exactly clear whether things like artifactId shouldn't be inherited. This will be one area we will need to discuss as we move toward mixins. > > 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? You raise some good points. I was struggling a bit with the terms here. I'll give it some more thought. > > 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. Locating parents fell a bit outside of this original spec, but I think it's worth adding something about how this is to be handled. We would need some rule that says a parent.version is not required. And also how to cover the situation where project.parent.version and project.version are both missing. Thanks, Shane
