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
