maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Scholte <>
Subject Re: Parent Version maybe not needed in child POM
Date Mon, 12 Dec 2016 09:42:19 GMT
Exactly! That's why we are thinking about a build pom and a distribution pom, which are now
always the same file. By splitting it, it will be possible to replace the relativePath with
the actual version. 
To be clear, developers will only have a build pom, the distribution pom will be generated
based on the build pom, probably during the package phase 


Verzonden vanaf Samsung Mobile.

<div>-------- Oorspronkelijk bericht --------</div><div>Van: Jörg Schaible
<> </div><div>Datum:12-12-2016  10:27  (GMT+01:00)
</div><div>Aan: </div><div>Onderwerp: Re: Parent
Version maybe not needed in child POM </div><div>
</div>Tibor Digana wrote:

> Is it really necessary to specify version of parent artifact in <parent/>?
> Suppose we have multimodule reactor project and maven-release-plugin would
> inline the version in the <parent/> section and remove it again in new
> development iteration. The plugin fails then if the parent version is not
> determined.
> If I specify {project.version} in child POM dependencies I do it for the
> reason to not to know anything about inconsistent versions. The parent
> section with specific version breaks this idea because the parent runs
> child and thus child should know the caller.
> Maybe groupId+artifactId+relativePath in parent would be enough in such
> project.

The problem starts when you get the child POM from a repository. And *a* 
repository might already be the local one. I.e. your suggestion with the 
automated manipluation must happen already at installation/deployment time.


To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message