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> 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.
