On 17-Dec-08, at 1:27 AM, Brett Porter wrote:
I fixed some typos - is it ok to regenerate the PDF? (mine comes out
slightly different on the Mac but it's all there AFAICT).
Just to add to what Brian and Ralph have already said:
3.1 - I think we have to knock multiple inheritance out at this
stage, even if it is noted as a possibility for general model
building, I don't think it's appropriate for the Maven rules.
3.2 - We should just define this by the current behaviour IMO, then
look at how we fix it going forward (See below on versioning)
That' s all we're doing. The general mechanism is built into the
builder for multiple inheritance the our constrained use only uses the
super pom, but mixins are also inherited models. It was hard enough to
sift backward and try and capture what it does and as I mentioned
before I don't see any real changes being made to behavior until at
least alpha-3.
3.3 - I had the same confusion as Brian. Why are collections not
joined?
Some more things:
1.1 - mentioned this before, but should be use a valid URI that
perhaps matches the POM namespace? http://maven.apache.org/POM/...
2.2 - I didn't see anything that says that in a set, a property
should overwrite a previous one if it already exists (and define how
equality is measured)?
2.2 - I think map handling needs to be defined for the same reason
so that duplicate keys can be merged
3.6.2 - why is the parent artifact ID listed in the (1-3) section?
3.6.2 - are join, nop and delete in a different order to the
following bullets?
3.8 - how are properties represented by XML elements in the current
schema handled in the URI? the "combine" technique is listed as a
property, but is the attribute actually recognised as something
different?
4.1 - refers to 3.4, but I think it means 3.6
4.1 - how is plugin configuration handled? it only details the
combination of the artifact portion. Should executions be explicitly
forbidden in the management just for clarity?
5.1.1 - timestamp format should be described?
5.1.1 - is the basedir absolute?
5.1.2 - this seems too "implementation specific"
5.1.4 - this is a self-referential definition. I don't think the
difference between types of properties is clear enough - maybe
defining system as dominant and environment as recessive is more
descriptive
5.2.2 - need to list what the build directory elements are
5.3 - profiles are not addressed elsewhere - should their processing
as an additional form of inheritance be described?
Versioning...
I really would like to understand how this is going to work. My
impression is the following:
- this document would be locked down to current behaviour as 4.0.0
(warts and all)
- a new version of the document would make addition and changes, and
would be a completely new rule set
- the URIs would be the same, not including a version.
- to operate on two versions of the model, the older would be
upgraded to the new one first by a mapping of properties from one to
the other. If the mapping was complicated it might need to be
handled by an external converter - but the inheritance should always
operate on two models of the same version. The problem here is that
you can no longer honour some of the older rules from inherited POMs
- but that may not be a serious consequence.
Is this what you expect?
BTW, should we now delete the wiki page that held basically the same
info?
Cheers,
Brett
On 17/12/2008, at 3:32 PM, Brian E. Fox wrote:
"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
--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
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
----------------------------------------------------------
We know what we are, but know not what we may be.
-- Shakespeare
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
