Mine below.
On Dec 16, 2008, at 10:36 PM, Shane Isbell wrote:
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.
OK. As I read 2.2 it basically only says the first definition wins.
2.1 talks about a collection of models, but it doesn't say anything
about dependency resolution, either directly or in its references to
section 3. In other words, I don't see anything that describes how the
version of an artifact is determined when that artifact occurs in
several places in the dependency tree.
2.4 The only "definition" of mixin is "The only diļ¬erence 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.
I guess I really have no clue what functionality a mixin is supposed
to provide or how it would be retrieved without a version or groupid.
Is it being suggested they would be stored in the repo without that?
I'd need a lot of convincing before I could buy off on that.
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).
Personally, I think that including them in this list is just
misleading. The effect is exactly the same.
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.
I think you should start another thread to explain what the concept of
mixins is. You referenced it once as the "solution" for importing
managed dependencies. Some concrete examples would be nice.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
