Op Tue, 27 Aug 2013 20:34:07 +0200 schreef Stephen Connolly
<[email protected]>:
On Tuesday, 27 August 2013, Robert Scholte wrote:
Op Tue, 27 Aug 2013 10:59:08 +0200 schreef Stephen Connolly <
[email protected]>:
On 27 August 2013 09:46, Stephen Connolly
<[email protected]>wrote:
On 27 August 2013 09:00, Jörg Schaible <[email protected]
>wrote:
> And since this would be for a new Maven, we need only concern
ourselves
> that the contract of the new Maven's classpath and property
behaviour
is
> correct... thus we don't have to preserve the current crazyiness
when
you
> have a dependency that has transitive dependencies where parts of
the
GAV
> are linked by properties.
I hope, you're only referring to the usage of properties for the
direct
project version and the parent. In dependencyManagement (and
pluginManagement) I really want to use distinct property constants
...
it
is
so much more convenient and less error-prone.
I am saying that the properties being in the deployed *these are the
runtime dependencies* pom causes issues...
So that when deploying the foo-1.0-build.pom we would put in the EL
expressions... but when deploying the foo-1.0-deps.pom we would fully
resolve them to the property values at build time. (might have an
exception
for the system scope's path... if we keep system scope) because that
frees
the consumers from having to interpolate the properties and build the
full
model.
In other words, we should make the -deps.pom easy to consume. The ${}
EL
expressions are exactly what you want in the human authored files...
just
not in the machine generated ones
By way of an example... your source code may have a pom file like:
<project>
<modelVersion>4.0.0</**modelVersion>
<parent>
<groupId>localdomain.example</**groupId>
<artifactId>parent</**artifactId>
<version>1.0-SNAPSHOT</**version>
</parent>
<artifactId>child</artifactId>
<properties>
<junit.version>4.0</junit.**version>
</properties>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>${junit.version}</**version>
</dependency>
</dependencies>
</project>
I'd like to go a bit further: the project's pom.xml could also be a
modelVersion 5.0.0, as long as the deployed child-1.0-SNAPSHOT.pom is
stripped/ported back to 4.0.0
I thought that was implicit... I was just showing how we could handle
building older poms too (in the don't throw the baby out with the bath
water, don't force people to rewrite their poms until they need a new
feature kind of way)
Perhaps I misjudged ;-)
check, check, double check :)
And yes: Both modelVersions should be supported
When that gets deployed *by mvn4*, we could be deploying:
* child-1.0-SNAPSHOT.pom
<project>
<modelVersion>4.0.0</**modelVersion>
<groupId>localdomain.example</**groupId>
<artifactId>child</artifactId>
<version>1.0-SNAPSHOT</**version>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.0</version>
</dependency>
</dependencies>
</project>
* child-1.0-SNAPSHOT-deps.pom
{
"modelVersion":"5.0.0",
"id":"localdomain.example:**child:1.0-SNAPSHOT",
"dependencies":[
"junit:junit:4.0"
]
}
* No child-1.0-SNAPSHOT-build.pom as the packaging is not `pom`
Thus legacy consumers have a pom that they can parse that conforms to
the
legacy classpath but provides faster resolution, modern consumers can
just
look up the -deps.pom directly and parse that (note that I gave a JSON
example both to be controvertial *and* to remind people that we can
pursue
other pom formats when we go to the next model version.
Now maybe there are issues with fully collapsing a modelVersion 4.0.0
pom
when building with mvn4... so perhaps mvn4 would need to just deploy a
modelVersion 4.0.0 pom as is, unmodified... that's fine IMHO... but
with a
modelVersion 5.0.0 pom in whatever format we pick for that, my opinion
is
that we should deploy the legacy pom fully resolved.
------------------------------**------------------------------**---------
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]
