Hi Stephen, Stephen Connolly wrote:
> 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 OK. This means all the stuff we have currently in the shared parent (depMgmt/pluginMgmt and properties) will stay in the *-build.pom and work in this regard like before. > 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. :) Actually I'd like to see a simplified format (at least usage of attributes e.g. for GAV in XML). > 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. In consequence this will also implicitly drop (transitive) dependency manipulations with profiles. However, all makes sense now to me - thanks for explaining. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
