Re: Parent Version maybe not needed in child POM

[Christian Schulte]

Am 12/13/16 um 07:33 schrieb Igor Fedorenko:
> But reactor dependencies make perfect sense in m2e! Also, keep in mind that 
> we are talking about new maven concept, it does not currently exist and 
> can't be supported by m2e, netbeans or any other existing tool.
> 

Last time I worked on a Maven project in Eclipse the IDE did not call a
single Maven plugin and did everything itself based on it's workspace
concept. Making Maven better suit Eclipse just should not lead to
loosing support in other IDEs. What makes no sense in Eclipse makes
perfect sense in Netbeans. The latter moved away from some kind of
workspace concept in version 4. See
 Project System Based
on Apache Ant. A lot of users were upset by that drastic change.
Introducing that new project system was one of the best decisions they
ever made. The IDE really calls Maven for everything.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Christian Schulte]

Am 12/13/16 um 06:04 schrieb Tibor Digana:
>>> Something like an J2EE
>>> You can take a long walk
>>> until it finishes downloading sources, javadoc, dependencies
>>> I really only open the module(s) I need
> This is not Maven problem then.
> You architect must give you a freedom to move some modules apart and keep
> some in it which makes the multi-module project as small as possible.
> It must be really something wrong with your architect because you are
> deploying SNAPSHOT versions to Nexus.

It's not that there are no open source projects around one can take a
look at. For example:




> So I only wanted to say that multi-module project can be made small if
> people have freedom to make it and then it is worth for them to still build
> it from the root and test few applications together. Minimizing the
> coupling and reorganizing cohesion is the way to reach the goal to have
> multiple trunks (deploy release versions) having small multi-module project
> (no snapshot deployment) in each trunk.

We are saying the same things, somehow. If you take a look at the
projects above, you can open any module you want in Netbeans without
having to open all of them. Cross reactor. That's the kind of freedom I
am talking about. Removing the reactor coordinates this will no longer
be possible.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Igor Fedorenko]

But reactor dependencies make perfect sense in m2e! Also, keep in mind that 
we are talking about new maven concept, it does not currently exist and 
can't be supported by m2e, netbeans or any other existing tool.


--
Regards,
Igor



On December 12, 2016 4:38:30 PM Christian Schulte  wrote:


Am 12/13/16 um 01:33 schrieb Igor Fedorenko:

This suggests inefficiency in existing implementation. We use this model
internally with some custom optimizations for a very large codebase.


Maybe. Netbeans is using the Maven API for all of this. It's like
building the full reactor on the command line with downloading source
jars and javadoc jars. That other IDE does not handle the artifacts as
artifacts but more or less views all of those artifacts as directories
in a common workspace and internally builds it's own classpaths and so
on. That's why the reactor coordinates do not seem to make any sense there.

Regards,
--
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Tibor Digana]

>>Something like an J2EE
>>You can take a long walk
>>until it finishes downloading sources, javadoc, dependencies
>>I really only open the module(s) I need
This is not Maven problem then.
You architect must give you a freedom to move some modules apart and keep
some in it which makes the multi-module project as small as possible.
It must be really something wrong with your architect because you are
deploying SNAPSHOT versions to Nexus.
We only use multi-module project if and only if all projects have
compilation dependencies AND common database model.
There are always things which can be split to another trunk, for instance
Audit module or GenericDao, generic JSF components, Crypto utilities. There
was something wrong with our architect because he wanted to have a shared
business:jar and therefore we decided to combine multiple trunks to one
trunk and multi-module project and split the business part and minimize
coupling between WAR files and avoid cohesion in business:jar. It will be
still multi-module project but smaller because we will push some code apart
in another trunk but keep all WAR files in it because they have common
database model. In our case Microservices do not make sense because the web
UI requires using complex SQL JOINs and combining all Microservices in one
Elastic database brings us to one database again. One way or another I want
to combine all 12 war files only to 3 War files because it makes sense
which will make the big project smaller again and again. (admin:war,
customer:war, schedulers:war)

So I only wanted to say that multi-module project can be made small if
people have freedom to make it and then it is worth for them to still build
it from the root and test few applications together. Minimizing the
coupling and reorganizing cohesion is the way to reach the goal to have
multiple trunks (deploy release versions) having small multi-module project
(no snapshot deployment) in each trunk.



On Tue, Dec 13, 2016 at 12:25 AM, Christian Schulte  wrote:

> Am 12/12/16 um 23:23 schrieb Igor Fedorenko:
> > Disagree. I think in most if not all cases we build entire project, not
> > just random part of a project.
>
> Try opening a big multi-module project in Netbeans, for example.
> Something like an J2EE application server. You can take a long walk
> until it finishes downloading sources, javadoc, dependencies and the
> background scanning task before you can change a single line of code.
> Working on projects like that, I really only open the module(s) I need
> to work on, build them in isolation and copy resuling jar files around -
> during development.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

Re: Parent Version maybe not needed in child POM

[Christian Schulte]

Am 12/13/16 um 01:33 schrieb Igor Fedorenko:
> This suggests inefficiency in existing implementation. We use this model 
> internally with some custom optimizations for a very large codebase.

Maybe. Netbeans is using the Maven API for all of this. It's like
building the full reactor on the command line with downloading source
jars and javadoc jars. That other IDE does not handle the artifacts as
artifacts but more or less views all of those artifacts as directories
in a common workspace and internally builds it's own classpaths and so
on. That's why the reactor coordinates do not seem to make any sense there.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Igor Fedorenko]

This suggests inefficiency in existing implementation. We use this model 
internally with some custom optimizations for a very large codebase.


--
Regards,
Igor



On December 12, 2016 3:25:35 PM Christian Schulte  wrote:


Am 12/12/16 um 23:23 schrieb Igor Fedorenko:

Disagree. I think in most if not all cases we build entire project, not
just random part of a project.


Try opening a big multi-module project in Netbeans, for example.
Something like an J2EE application server. You can take a long walk
until it finishes downloading sources, javadoc, dependencies and the
background scanning task before you can change a single line of code.
Working on projects like that, I really only open the module(s) I need
to work on, build them in isolation and copy resuling jar files around -
during development.





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Christian Schulte]

Am 12/13/16 um 01:07 schrieb Manfred Moser:
> All of these task should only happen when you open a new project. Otherwise 
> all of it should be cached in the local repo.
> 
> When all of it is local it should NOT take so long. At least it doesnt in 
> M2e. If you resort to a hack like opening only part of the reactor you should 
> not be surprised if working on it is only semi-optimal.
> 

It's the opposite here. Opening a few modules takes a few seconds.
Opening a larger reactor takes ages. It needs to build tons of effective
models (processing imports etc.) vs. it needs to build just a few
effective models. I know nothing about m2e, so cannot comment on that. A
quick look tells me it's about an IDE refusing to give up on concepts
from the middleages (workspaces, projects) when all others have adopted
artifact based concepts for more than a decade.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Manfred Moser]

All of these task should only happen when you open a new project. Otherwise all 
of it should be cached in the local repo.

When all of it is local it should NOT take so long. At least it doesnt in M2e. 
If you resort to a hack like opening only part of the reactor you should not be 
surprised if working on it is only semi-optimal.

Manfred

Christian Schulte wrote on 2016-12-12 15:25:

> Am 12/12/16 um 23:23 schrieb Igor Fedorenko:
>> Disagree. I think in most if not all cases we build entire project, not 
>> just random part of a project.
> 
> Try opening a big multi-module project in Netbeans, for example.
> Something like an J2EE application server. You can take a long walk
> until it finishes downloading sources, javadoc, dependencies and the
> background scanning task before you can change a single line of code.
> Working on projects like that, I really only open the module(s) I need
> to work on, build them in isolation and copy resuling jar files around -
> during development.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Christian Schulte]

Am 12/12/16 um 23:23 schrieb Igor Fedorenko:
> Disagree. I think in most if not all cases we build entire project, not 
> just random part of a project.

Try opening a big multi-module project in Netbeans, for example.
Something like an J2EE application server. You can take a long walk
until it finishes downloading sources, javadoc, dependencies and the
background scanning task before you can change a single line of code.
Working on projects like that, I really only open the module(s) I need
to work on, build them in isolation and copy resuling jar files around -
during development.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Igor Fedorenko]

-am should be aware of entire multimodule project and resolve in reactor 
dependencies accordingly.


--
Regards,
Igor



On December 12, 2016 2:36:08 PM "Robert Scholte"  wrote:


Absolutely agreeing with Igor. And if you want to be able to build a
single module of a multimodule without -am it is *your* responsibility to
add the versions to those dependencies, so these are pulled from a
repository.
That will still work, but will remove the safety belt (jigsaw(tm)?)

Robert

On Mon, 12 Dec 2016 23:23:51 +0100, Igor Fedorenko 
wrote:


Disagree. I think in most if not all cases we build entire project, not
just random part of a project.


Regards,
Igor



On December 12, 2016 11:22:50 AM Christian Schulte  wrote:


Am 12/12/16 um 10:16 schrieb Tibor Digana:

Is it really necessary to specify version of parent artifact in
?


It must be possible to checkout a single module and build that in
isolation. A parent without a version cannot be resolved from a
repository. Supporting that means you need to checkout the whole project
(can be very huge) just to be able to find the parent on disk.
Installing/deploying an artifact without version is impossible -
incomplete coordinates. So there needs to be a version as soon as an
artifact is to be installed or deployed.

Regards,
--
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Robert Scholte]

Absolutely agreeing with Igor. And if you want to be able to build a  
single module of a multimodule without -am it is *your* responsibility to  
add the versions to those dependencies, so these are pulled from a  
repository.

That will still work, but will remove the safety belt (jigsaw(tm)?)

Robert

On Mon, 12 Dec 2016 23:23:51 +0100, Igor Fedorenko   
wrote:


Disagree. I think in most if not all cases we build entire project, not  
just random part of a project.



Regards,
Igor



On December 12, 2016 11:22:50 AM Christian Schulte  wrote:


Am 12/12/16 um 10:16 schrieb Tibor Digana:
Is it really necessary to specify version of parent artifact in  
?


It must be possible to checkout a single module and build that in
isolation. A parent without a version cannot be resolved from a
repository. Supporting that means you need to checkout the whole project
(can be very huge) just to be able to find the parent on disk.
Installing/deploying an artifact without version is impossible -
incomplete coordinates. So there needs to be a version as soon as an
artifact is to be installed or deployed.

Regards,
--
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Igor Fedorenko]

Disagree. I think in most if not all cases we build entire project, not 
just random part of a project.



Regards,
Igor



On December 12, 2016 11:22:50 AM Christian Schulte  wrote:


Am 12/12/16 um 10:16 schrieb Tibor Digana:

Is it really necessary to specify version of parent artifact in ?


It must be possible to checkout a single module and build that in
isolation. A parent without a version cannot be resolved from a
repository. Supporting that means you need to checkout the whole project
(can be very huge) just to be able to find the parent on disk.
Installing/deploying an artifact without version is impossible -
incomplete coordinates. So there needs to be a version as soon as an
artifact is to be installed or deployed.

Regards,
--
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Christian Schulte]

Am 12.12.2016 um 21:32 schrieb Tibor Digana:
> The IDEs like Eclipse, IDEA etc must adapt to versionless parent.
> 
> @Christian
> Execution of large projects and parent version depends on development team.
> Nowadays they are going to be Microservices very small and isolated in
> build time and runtime as well.
> It really depends on the needs. For instance nowadays I can non-recursively
> -N release a parent and a specific child -pl can be released separately and
> release plugin will ask me what is the release version of parent.
> 
> If Maven had continuous build based on SCM information, I would not care if
> I run the build from the root even if I want to build only changed child
> somewhere deeply in the tree.
> Actually this is the feature I am missing in Maven and installing Jenkins
> for that, no developer would do.
> 
> But logically if such large structure will always be built from root
> because of such coupling and because of all WAR file always will be
> deployed to JBoss together at the same time because they have common
> database model, then it makes perfect sense not to have intermediate Parent
> sections because this is one big consistent structure and always will be.

You wouldn't need an artifact based build system for this. One big 'src'
folder and one big 'classes' folder and packages build based on
directory/package names. You'll loose all kind of scoping that way, of
course. You are never deploying artifacts to a repository? So you only
deploy the final WAR files and that's it?

> And again if a developer wants to build a part of that then still can do
> that in the same manner but continuous Maven core should ask SCM for
> changes after last build time and build always only changed modules which
> would be perfect, would not it be?

Job of the CI system, IMHO. It's a matter of how you use to work. I am
used to only checkout what I need to work on and rely on Maven to
download the missing pieces from repositories for me. Makes a lot of
sense. If this will no longer be possible, I simply would not know how
to open such a project in my IDE of choice. Before Maven, there was no
way to just open a project in the IDE. You always needed to setup some
kind of project for each and every bit. Maven has made life so much
easier. I haven't had to manually setup a project in the IDE since
years. This is a must have for me. I am not objecting your use case. I
just would not want an artifact based build system to go the "monolithic
project structure" way.

Regards,
-- 
Christian



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Tibor Digana]

The IDEs like Eclipse, IDEA etc must adapt to versionless parent.

@Christian
Execution of large projects and parent version depends on development team.
Nowadays they are going to be Microservices very small and isolated in
build time and runtime as well.
It really depends on the needs. For instance nowadays I can non-recursively
-N release a parent and a specific child -pl can be released separately and
release plugin will ask me what is the release version of parent.

If Maven had continuous build based on SCM information, I would not care if
I run the build from the root even if I want to build only changed child
somewhere deeply in the tree.
Actually this is the feature I am missing in Maven and installing Jenkins
for that, no developer would do.

But logically if such large structure will always be built from root
because of such coupling and because of all WAR file always will be
deployed to JBoss together at the same time because they have common
database model, then it makes perfect sense not to have intermediate Parent
sections because this is one big consistent structure and always will be.
And again if a developer wants to build a part of that then still can do
that in the same manner but continuous Maven core should ask SCM for
changes after last build time and build always only changed modules which
would be perfect, would not it be?





On Mon, Dec 12, 2016 at 8:22 PM, Christian Schulte  wrote:

> Am 12/12/16 um 10:16 schrieb Tibor Digana:
> > Is it really necessary to specify version of parent artifact in
> ?
>
> It must be possible to checkout a single module and build that in
> isolation. A parent without a version cannot be resolved from a
> repository. Supporting that means you need to checkout the whole project
> (can be very huge) just to be able to find the parent on disk.
> Installing/deploying an artifact without version is impossible -
> incomplete coordinates. So there needs to be a version as soon as an
> artifact is to be installed or deployed.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

Re: Parent Version maybe not needed in child POM

[Martijn Dashorst]

On Mon, Dec 12, 2016 at 8:22 PM, Christian Schulte  wrote:
> Am 12/12/16 um 10:16 schrieb Tibor Digana:
>> Is it really necessary to specify version of parent artifact in ?
>
> It must be possible to checkout a single module and build that in
> isolation. A parent without a version cannot be resolved from a
> repository. Supporting that means you need to checkout the whole project
> (can be very huge) just to be able to find the parent on disk.
> Installing/deploying an artifact without version is impossible -
> incomplete coordinates. So there needs to be a version as soon as an
> artifact is to be installed or deployed.

But is it really a requirement that the version MUST be there always?
I never encountered your specific requirement, but I can imagine it be
necessary some times. But I can give you enough examples where your
requirement isn't necessary and the version can be omitted.

So, if you need need to checkout a submodule stand alone, then one
should include the version, but if that is not a use case, one can
omit the version and instead rely on the parent's module's version.

Martijn

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Christian Schulte]

Am 12/12/16 um 10:16 schrieb Tibor Digana:
> Is it really necessary to specify version of parent artifact in ?

It must be possible to checkout a single module and build that in
isolation. A parent without a version cannot be resolved from a
repository. Supporting that means you need to checkout the whole project
(can be very huge) just to be able to find the parent on disk.
Installing/deploying an artifact without version is impossible -
incomplete coordinates. So there needs to be a version as soon as an
artifact is to be installed or deployed.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Robert Scholte]

I forgot to mention that this must work for SNAPSHOTs as well, which  
confirms this is not something which needs to be resolved with the  
maven-release-plugin, but in Maven Core.


Robert

On Mon, 12 Dec 2016 10:16:46 +0100, Tibor Digana   
wrote:


Is it really necessary to specify version of parent artifact in  
?


Suppose we have multimodule reactor project and maven-release-plugin  
would

inline the version in the  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.

Cheers
Tibor


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Igor Fedorenko]

I think this is a good idea. And I'd go one step further and use 
"versionless"  to represent in-reactor version.


--
Regards,
Igor



On December 12, 2016 1:16:49 AM Tibor Digana  wrote:


Is it really necessary to specify version of parent artifact in ?

Suppose we have multimodule reactor project and maven-release-plugin would
inline the version in the  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.

Cheers
Tibor




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Parent Version maybe not needed in child POM

[Robert Scholte]

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.

 Oorspronkelijk bericht Van: Jörg Schaible 
<joerg.schai...@bpm-inspire.com> Datum:12-12-2016  10:27  
(GMT+01:00) Aan: dev@maven.apache.org Onderwerp: Re: 
Parent Version maybe not needed in child POM 
Tibor Digana wrote:

> Is it really necessary to specify version of parent artifact in ?
> 
> Suppose we have multimodule reactor project and maven-release-plugin would
> inline the version in the  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

Re: Parent Version maybe not needed in child POM

[Jörg Schaible]

Tibor Digana wrote:

> Is it really necessary to specify version of parent artifact in ?
> 
> Suppose we have multimodule reactor project and maven-release-plugin would
> inline the version in the  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

Parent Version maybe not needed in child POM

[Tibor Digana]

Is it really necessary to specify version of parent artifact in ?

Suppose we have multimodule reactor project and maven-release-plugin would
inline the version in the  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.

Cheers
Tibor