On 23 August 2013 05:30, Mark Derricutt <m...@talios.com> wrote: > On 23/08/2013, at 3:50 PM, Domi <d...@fortysix.ch> wrote: > > Should maven not have a Concept to support multiple schema versions? > > > In theory it does, by way of the DTD declaration, you can specify which > DTD you're currently using, but support for that POM version would mandate > a minimum version of Maven for the build. >
The real problem is that it is no longer just Maven that is parsing the POM files. We have Buildr, Ivy, etc all reading POM files... And then you have the issue where your favourite dependency has upgraded to Maven 5.0 so their poms are only 5.0+ compatible and you are stuck building with 3.2 which means that you cannot even consume those dependencies... Aha! You say... "Why not deploy a modelVersion=4.0.0 pom to central *and* a modelVersion=5.0.0 only deploy the 5.0.0 version with a classifier" Then we have doubled the requests that Maven needs to make *and* what happens for the next time? will we be deploying to central foo-1.0.pom foo-1.0-model5.0.0.pom foo-1.0-model5.1.0.pom foo-1.0-model5.2.0.pom foo-1.0-model6.0.0.pom foo-1.0-model7.0.0.pom in 3 years time? That's not going to scale. The best we can do is try and ensure that modelVersion=5.0.0 is such that it can be extended in a way that lets us move forward *without* needing many many different pom formats... One (partial) solution I have thought of is that we could leverage the central repository to allow adapting to future model versions... e.g. if Maven/buildr/ivy/etc sees a model version they don't know they can look up for their own down-translating parser from central (and if they haven't got one perhaps - and this assumes we keep xml as the pom format - pick up an XSLT stylesheet to at least map it back to a 5.0.0 compatible model) In such a scheme, if Maven 4.0 picks up foo-1.0-model5.pom and sees it has a modelVersion=7.0.0 (which is newer than the 5.0.0 it understands) it might go and look for org.apache.maven:model-mapping-5:[7.0,8.0):jar, which if it finds it will use to convert the 7.0.0 model version to a model that it understands... if there is no such mapping it would look for org.apache.maven:model-mapping-xslt:7.0.0:xsl and use that to strip out the 7.0.0 and 6.0.0 specific features to retain a 5.0.0 parsable pom Oh but there are sooo many holes and bad ideas about the above... And yet this is a problem we need to solve, because we cannot move the POM forward without solving it, and we need to move the POM forward. > > Which I'd be down for - if maven encountered a DTD version it didn't > understand, gracefully handle it with suitable error messages that identify > the problem as being either a totally broken pom.xml, or an unsupported POM > version - of which, if thats the case then the POM should include a: > > <prerequisites> > <maven>2.0.6</maven> > </prerequisites> > > > section or something. > >
