I haven't seen this proposal before, I can't find anything about it on our
wiki[1]
Benson started a page[2] in the past, but that doesn't cover it all.
Would be nice to collect these kind of info
Robert
[1]
https://cwiki.apache.org/confluence/pages/listpages-alphaview.action?key=MAVEN
[2]
https://cwiki.apache.org/confluence/display/MAVEN/Moving+forward+with+the+POM+data+model
Op Fri, 23 Aug 2013 17:13:43 +0200 schreef Stephen Connolly
<stephen.alan.conno...@gmail.com>:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
