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
Robert
Verzonden vanaf Samsung Mobile.
<div>-------- Oorspronkelijk bericht --------</div><div>Van: Jörg Schaible
<joerg.schai...@bpm-inspire.com> </div><div>Datum:12-12-2016 10:27
(GMT+01:00) </div><div>Aan: dev@maven.apache.org </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.
>
> WDYT?
>
> 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.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
