Comments below: On Tue, Dec 16, 2008 at 10:27 PM, Brett Porter <br...@apache.org> 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. I know we are playing with definitions here; but if someone chooses to define a complete pom as a mixin, then it's the same as multiple inheritance. > > 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) > 3.3 - I had the same confusion as Brian. Why are collections not joined? I'm just defining current behavior in regards to these collections. If the spec doesn't match current behavior, then we need to modify the spec. > > > 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/... I don't care either way. If people want a different base URI, it's fine with me. > > 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)? The first unique element of the set takes priority, which means most specialized pom (least child). It can't be overridden. > > 2.2 - I think map handling needs to be defined for the same reason so that > duplicate keys can be merged I need more information about what you are thinking here. > > 3.6.2 - why is the parent artifact ID listed in the (1-3) section? This needs to be removed from the spec. > > 3.6.2 - are join, nop and delete in a different order to the following > bullets? The ordering is correct. Initially all elements of the child and parent (with the exception of duplicate singletons) are placed into one set. A NOP means that no operation is done, leaving B set Union alpha. > > 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? There is a #property element defined in the URI. In the case of XML, the model would unmarshal that model property as an XML property. The combine.children property is handled as a general rule in model-builder. > > 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? Yes, it should be but the profile implementation in maven-project-builder has not yet been integrated with the rest of trunk, so I'm holding of on trying to define that part of the spec. > > > 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) As close as possible. > > - a new version of the document would make addition and changes, and would > be a completely new rule set There a lot of general rules of inhertance (sets, collections, sorting), but anything dealing with maven specific processing could change. > > - the URIs would be the same, not including a version. Yes, but there may be additional elements added to newer versions. > > - 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. If there are two different versions of the model, then you would likely use the version of the PomTransformer for that model version. Transforming between models is a different case, where you have a completely different project format that you want to put into the canonical data format and have it processed as though it were a pom. > > > 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 > >
