> > > Remark: the current pom:validate goal works to some extent > even for poms that extend others. Having a valid > a/project.xml and a b/project.xml with only > <extend>../a/project.xml</extend> in it, validates b. Making > an invalid change to a's pom then makes the validation on b > fail as well.
Good feature. I didn't used it. > > However, it doesn't work if I set some minOccurs in the > schema file to 1, in that case the validation of b will fail > even if the corresponding element is present in a. > > > What about the following suggestion: we introduce two > schemas, maven-pom-strict and maven-pom-extend. Every > stand-alone pom has to comply with pom-strict and every pom > that extends another one has to extend at least one strictly > valid pom. > > [This doesn't eliminate some exotic setup's where you have a > chain of poms that are each invalid by themselves, but when > merged together make up a valid one. I don't know if this is > a frequent case.] We should maintain 2 schemas :-( Or can we generate the maven-pom-extend from maven-pom-strict. I'm not sure if it's very useful..... Arnaud > > > -Lukas > > > Arnaud HERITIER wrote: > > The only solution is to do what is already done actually... > > > > 1) We can't have a schema more restrictive because each > element is optional if you use the POM's inheritence. > > 2) We can't easily merged project.xml files because there > are several > > rules : some elements replace the ones in the parent and > some others are in addition to them (and it will as > complicated as the 3rd proposal). > > 3) We can't test the rewritten POM because it will not be > easy to explain to the user where the problem is ... > > > > The real question we should ask to ourselves it's why we > need a schema for the POM ? > > After thinking about it I'm not sure it's a good idea to > validate the > > POM with a schema :-( The schema (in my opinion) should be used > > exclusively to help users to create the project.xml file > (using an xml editor which propose it if they don't already > use a tool like mevenide). > > The validation of the POM should be done by the core itself (with a > > validate method in the Project object -even if I don't know what we > > can test) and an explicit message should be return if > there's a problem. ==> It should be also the model which log > a message if a plugin tries to use an element in the POM > which is not defined (The test shouldn't be done in the plugin) .... > > > > But I think that all these ideas aren't possible to > implement to keep > > the compability between maven 10 and maven 1.1 :-( Thus I > think we must keep things as more simple as possible. > > > > WDYT ? > > > > Arnaud > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
