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 ;-)
>
>
> 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]
>
>
--
Sent from my phone
