maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: Adding support for new dependency mediation strategy
Date Tue, 27 Aug 2013 18:08:06 GMT
Op Tue, 27 Aug 2013 10:59:08 +0200 schreef Stephen Connolly  
<stephen.alan.connolly@gmail.com>:

> On 27 August 2013 09:46, Stephen Connolly
> <stephen.alan.connolly@gmail.com>wrote:
>
>> On 27 August 2013 09:00, Jörg Schaible  
>> <Joerg.Schaible@scalaris.com>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


> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message