On 16-Dec-08, at 3:58 AM, Ralph Goers 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:
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.
We should definitely add them to the appendix. If you actually look at
the implementation the parsers are domain specific and they produce
the set of model properties. I think Shane did what was correct in
that he focused on a concrete implementation and got it working. So
right now the domain specific parser is hand-written. There is no
reason that this parser cannot be generated with modello and when we
do that we can use the descriptions in the modello model to generate
an appendix with a description of each property.
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?
Let me add actual examples with POMs and I think it will be more clear.
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)?
It can be. The Maven POMs exhibit this property and it works fine so
I'll fix that.
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.
Yup.
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 think if it has anything to do with POM construction then we need to
include it in this document.
I hope this was the kind of feedback you were looking for.
This is great feedback. I'll get this converted into Confluence by the
end of the week and then it will be easier to collaborate. Shane also
reversed engineered the rules because nothing was ever documented as
it grew organically. I think a few rounds of doing this where we
clarify and the rules and we'll be in a lot better shape. I have
started a POM construction test suite which will act as a validation
for the specification which will be complete by alpha-2. For alpha-1 I
had the goal of some specific builds working to get the ball rolling.
The rigor will start after alpha-2 which combined with some of the
integration testing tools we have I think will ensure we go forward
and never backward again.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
