On 23 August 2013 15:57, Robert Scholte <rfscho...@apache.org> wrote:
> I fully agree with Stephen, and it made me realize something: > > The pom is all about build instructions. *When* (let's say 'when' instead > of 'if' ;) ) there's a newer pom model, it requires at least a newer > version of Maven (4+) to build that project. > However, if the project is deployed to a repository like Maven Central > only a small part is very interesting: parent, GAV, dependencies, > dependencyManagement (maybe a bit more...). But things like build and > reporting are probably not of interest anymore. > > So new elements inside <build> or <reporting> should have no effect. Maven > uses a strict PomReader, so new elements with the default namespace will > cause a failure. > It's better than that... I am not sure if I said it earlier or not, so I will try to say it now. When we get the next format, there are probably actually three files we want to deploy: foo-1.0.pom (the legacy 4.0.0 model) foo-1.0-build.pom (the new 5.0.0+ model) foo-1.0-deps.pom (the new 5.0.0+ model) Now foo-1.0.pom should be a resolved pom with only the bare minimum required elements, e.g. dependencies and hopefully nothing else... may need dependencyManagement, but I think we can collapse that down. No <parent> element. It would be a best effort mapping of dependencies, so any new scopes that we add will be collapsed into the closest fit of what we currently have. New features like <provides> will be mapped to <exclusions> for all the dependencies. That should preserve inter-op of legacy clients. The foo-1.0-deps.pom should be an XML format stripped pom with just dependency and provides information, but exposing the new dependency information. This pom is designed to be consumed for building the tree of dependencies and should be a fairly simple strict format so that 3rd party consumers can just use it directly. No <parent> element. The foo-1.0-build.pom is in whatever format we choose for poms. This is the one you look for when resolving <parent> tags. It is only needed at build time, and as such, deployment is optional, but if you don't deploy it, you cannot inherit from it. It also only gets deployed when <packaging>pom</packaging> which simplifies things greatly. When looking at <parent> there is a simple rule we can apply.... you cannot inherit from a parent that has a newer modelVersion than your modelVersion. Bang! There goes a lot of the inter-op problems in one fell swoop. Also lets us change from XML to something less "ugly" if we so choose. We only need the -deps.pom to be interop up and down... which means that the problem becomes smaller. > It might be worth investigating what happens if the installed/deployed pom > which only includes the bare minimum. (And the pom.xml inside the META-INF > of the artifact should still be the original of course) > > Now, if something has to be changed for dependencies/**dependencyManagement > then you probably have to force users to use a newer version of Maven, > since you expect a different behavior for the dependency resolution. > > I see options for new elements during project build time, but not for > "dependency-resolution" time right now. > > Robert > > > Op Fri, 23 Aug 2013 12:14:04 +0200 schreef Stephen Connolly < > stephen.alan.connolly@gmail.**com <stephen.alan.conno...@gmail.com>>: > > > 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. >>> >>> > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> > For additional commands, e-mail: dev-h...@maven.apache.org > >
