Re: How to arrange dependency management for maven reactor if child modules are versioned independently?
I do not like any uncertainty about what is going into a build.
If you are a developer and suddenly your code changes behaviour after
you have made a change, your natural assumption is that you broke it.
SNAPSHOTS are hard enough to deal with and you need manual policies
about snapshot deployment to ensure that publishing new snapshots is
communicated to everyone in the project and holding publishers to an
implied warranty (they may have to buy the next round if they break
someone else's code!).
At least the POM tells you if you are depending on a SNAPSHOT.
Having variability in releases just adds to the confusion.
Ron
On 02/07/2015 3:54 AM, Stefan Seidel wrote:
Hi,
So the release of submodule because of this reason is nothing significant
from the point of view of the whole platform and all the internal
dependencies should continue with the highest snapshot versions with as
small effort as possible. I hope this does makes sense.
If I understand this correctly, wouldn't using version ranges solve this? We
also update micro-projects often and so we use limites version ranges within
major releases, so [2,3) will resolve to the latest
snapshot or release of the dependency unless it had received a major upgrade
from, say, 2.8 to 3.0 or even 3.0-SNAPSHOT.
Regards,
Stefan
František
http://calavera.info
Původní zpráva
Od: Ron Wheeler
Odesláno: středa, 1. července 2015 17:14
Komu: users@maven.apache.org
Odpovědět: Maven Users List
Předmět: Re: How to arrange dependency management for maven reactor if child
modules are versioned independently?
What is the relationship between the "independent" modules?
If a child module gets a new version, should that trigger a change for
other modules that depend on it?
It seems to me from your description, that you do care when a child
module releases a new version.
If this should trigger a change in the dependant modules, then it seems
reasonable that the parent pom should change to make this explicit.
I would take a few seconds to think about how you want SNAPSHOTs to be
handled.
If A depends on B and B goes from 1.2.3 to 1.2.4-SNAPSHOT, do you want A
to start to depend on the SNAPSHOT immediately or to continue to use
1.2.3 until 1.2.4 is released?
You may need to separate the dependency versions from the artifact
version if you want to keep A depending on the released version of B.
1.2.4-SNAPSHOT
1.2.3
This will also allow the developer of B to test the impact on module A
by setting B.current.release.version to 1.2.4-SNAPSHOT to build and test
A prior to releasing B.
Ron
On 01/07/2015 6:35 AM, František Řezáč wrote:
Hi,
I have asked a question on stackoverflow about what I thought should be a
relatively common scenario but I didn't get an answer even though I put a
bounty on it and published it through my social networks to wide audience.
Since it's still unanswered after a long time, I'm sending it here as a
last hope for solution or expert insight.
http://stackoverflow.com/questions/30253133/how-to-arrange-dependency-mana
gement-for-maven-reactor-if-child-modules-are-vers
We have a reactor pom whose child modules are versioned independently, ie.
child module declares it's own version that is independent of the version
of the main pom. There is however a dependency between two child modules.
How should be this dependency configured to always use the version that is
declared by the actual module of the reactor pom?
I would expect that I can set up dependency management in the root pom and
use some implicit properties to determine the version of child modules,
but
the best such option I can find :
${session.projectDependencyGraph.sortedProjects[0].version}
or simply
${reactorProjects[0].version}
looks unreliable because the reactor order may change when new modules or
dependencies are added.
Maybe this usage scenario is discouraged by design and then I would like
to
know why.
As is suggested in comments in original stackoverflow post, declaring a
global properties with child versions in parent POM may be an option for
newer versions of Maven. I would however like to see some analysis with
respect to wider consequences like workflow, releasing, directory and
repository settings, some plugins usage (e.g. version plugin) etc. For
example I think that direct consequence of this approach is that I would
have to release parent module whenever any of child modules are released.
Although this is doable, it would impact the original idea of having an
independent versioning.
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to arrange dependency management for maven reactor if child modules are versioned independently?
Well that is if version ranges worked by magic...
How does [2,3) know that it is supposed to prefer the version from your
reactor?
If you are following some semver-like [1] versioning scheme, then you
should be building against 2 and running tests against any random *release*
(or all releases... but that could give many many releases) in the version
range [2,3)
Once you need the additional API in 2.0.67-SNAPSHOT you are still going to
have to update the range to [2.0.67-SNAPSHOT,3) because you can no-longer
compile against [2,2.0.66]... but hang on, wait a sec, now we have a
-SNAPSHOT in the bounds so we will resolve -SNAPSHOT versions too (let's
ignore the current bug on always resolving -SNAPSHOTs and talk about how it
is supposed to work) that's not good.
[1] semver has issues in some people's eyes, see
http://javaadventure.blogspot.ie/2014/09/version-numbers.html for my
contribution to that debate
On 2 July 2015 at 08:54, Stefan Seidel wrote:
> Hi,
>
> > So the release of submodule because of this reason is nothing significant
> > from the point of view of the whole platform and all the internal
> > dependencies should continue with the highest snapshot versions with as
> > small effort as possible. I hope this does makes sense.
>
> If I understand this correctly, wouldn't using version ranges solve this?
> We
> also update micro-projects often and so we use limites version ranges
> within
> major releases, so [2,3) will resolve to the latest
> snapshot or release of the dependency unless it had received a major
> upgrade
> from, say, 2.8 to 3.0 or even 3.0-SNAPSHOT.
>
> Regards,
>
> Stefan
>
> >
> > František
> > http://calavera.info
> >
> > Původní zpráva
> > Od: Ron Wheeler
> > Odesláno: středa, 1. července 2015 17:14
> > Komu: users@maven.apache.org
> > Odpovědět: Maven Users List
> > Předmět: Re: How to arrange dependency management for maven reactor if
> child
> > modules are versioned independently?
> >
> > What is the relationship between the "independent" modules?
> > If a child module gets a new version, should that trigger a change for
> > other modules that depend on it?
> > It seems to me from your description, that you do care when a child
> > module releases a new version.
> > If this should trigger a change in the dependant modules, then it seems
> > reasonable that the parent pom should change to make this explicit.
> >
> > I would take a few seconds to think about how you want SNAPSHOTs to be
> > handled.
> > If A depends on B and B goes from 1.2.3 to 1.2.4-SNAPSHOT, do you want A
> > to start to depend on the SNAPSHOT immediately or to continue to use
> > 1.2.3 until 1.2.4 is released?
> > You may need to separate the dependency versions from the artifact
> > version if you want to keep A depending on the released version of B.
> >
> > 1.2.4-SNAPSHOT
> > 1.2.3
> >
> >
> > This will also allow the developer of B to test the impact on module A
> > by setting B.current.release.version to 1.2.4-SNAPSHOT to build and test
> > A prior to releasing B.
> >
> > Ron
> >
> > On 01/07/2015 6:35 AM, František Řezáč wrote:
> > > Hi,
> > > I have asked a question on stackoverflow about what I thought should
> be a
> > > relatively common scenario but I didn't get an answer even though I
> put a
> > > bounty on it and published it through my social networks to wide
> audience.
> > > Since it's still unanswered after a long time, I'm sending it here as a
> > > last hope for solution or expert insight.
> > >
> > >
> http://stackoverflow.com/questions/30253133/how-to-arrange-dependency-mana
> > > gement-for-maven-reactor-if-child-modules-are-vers
> > >
> > > We have a reactor pom whose child modules are versioned independently,
> ie.
> > > child module declares it's own version that is independent of the
> version
> > > of the main pom. There is however a dependency between two child
> modules.
> > > How should be this dependency configured to always use the version
> that is
> > > declared by the actual module of the reactor pom?
> > >
> > > I would expect that I can set up dependency management in the root pom
> and
> > > use some implicit properties to determine the version of child modules,
> > > but
> > > the best such option I can find :
> > >
> > > ${session.projectDependencyGraph.sortedProjects[0].version}
> > >
> > > or simply
> > >
> > > ${reactorProjects[0].version}
Re: How to arrange dependency management for maven reactor if child modules are versioned independently?
Hi,
> So the release of submodule because of this reason is nothing significant
> from the point of view of the whole platform and all the internal
> dependencies should continue with the highest snapshot versions with as
> small effort as possible. I hope this does makes sense.
If I understand this correctly, wouldn't using version ranges solve this? We
also update micro-projects often and so we use limites version ranges within
major releases, so [2,3) will resolve to the latest
snapshot or release of the dependency unless it had received a major upgrade
from, say, 2.8 to 3.0 or even 3.0-SNAPSHOT.
Regards,
Stefan
>
> František
> http://calavera.info
>
> Původní zpráva
> Od: Ron Wheeler
> Odesláno: středa, 1. července 2015 17:14
> Komu: users@maven.apache.org
> Odpovědět: Maven Users List
> Předmět: Re: How to arrange dependency management for maven reactor if child
> modules are versioned independently?
>
> What is the relationship between the "independent" modules?
> If a child module gets a new version, should that trigger a change for
> other modules that depend on it?
> It seems to me from your description, that you do care when a child
> module releases a new version.
> If this should trigger a change in the dependant modules, then it seems
> reasonable that the parent pom should change to make this explicit.
>
> I would take a few seconds to think about how you want SNAPSHOTs to be
> handled.
> If A depends on B and B goes from 1.2.3 to 1.2.4-SNAPSHOT, do you want A
> to start to depend on the SNAPSHOT immediately or to continue to use
> 1.2.3 until 1.2.4 is released?
> You may need to separate the dependency versions from the artifact
> version if you want to keep A depending on the released version of B.
>
> 1.2.4-SNAPSHOT
> 1.2.3
>
>
> This will also allow the developer of B to test the impact on module A
> by setting B.current.release.version to 1.2.4-SNAPSHOT to build and test
> A prior to releasing B.
>
> Ron
>
> On 01/07/2015 6:35 AM, František Řezáč wrote:
> > Hi,
> > I have asked a question on stackoverflow about what I thought should be a
> > relatively common scenario but I didn't get an answer even though I put a
> > bounty on it and published it through my social networks to wide audience.
> > Since it's still unanswered after a long time, I'm sending it here as a
> > last hope for solution or expert insight.
> >
> > http://stackoverflow.com/questions/30253133/how-to-arrange-dependency-mana
> > gement-for-maven-reactor-if-child-modules-are-vers
> >
> > We have a reactor pom whose child modules are versioned independently, ie.
> > child module declares it's own version that is independent of the version
> > of the main pom. There is however a dependency between two child modules.
> > How should be this dependency configured to always use the version that is
> > declared by the actual module of the reactor pom?
> >
> > I would expect that I can set up dependency management in the root pom and
> > use some implicit properties to determine the version of child modules,
> > but
> > the best such option I can find :
> >
> > ${session.projectDependencyGraph.sortedProjects[0].version}
> >
> > or simply
> >
> > ${reactorProjects[0].version}
> >
> > looks unreliable because the reactor order may change when new modules or
> > dependencies are added.
> >
> > Maybe this usage scenario is discouraged by design and then I would like
> > to
> > know why.
> >
> > As is suggested in comments in original stackoverflow post, declaring a
> > global properties with child versions in parent POM may be an option for
> > newer versions of Maven. I would however like to see some analysis with
> > respect to wider consequences like workflow, releasing, directory and
> > repository settings, some plugins usage (e.g. version plugin) etc. For
> > example I think that direct consequence of this approach is that I would
> > have to release parent module whenever any of child modules are released.
> > Although this is doable, it would impact the original idea of having an
> > independent versioning.
--
Stefan Seidel
Projektleiter IT
___
vub | Wissen mit System | Chopinstraße 4, 04103 Leipzig
tel.+49 341 99 99 00 15
mail. ssei...@vub.de
web.www.vub.de
HRB Köln 24015 | Dr.C.Preuss-Neudorf
Re: How to arrange dependency management for maven reactor if child modules are versioned independently?
On 1 July 2015 at 11:35, František Řezáč
wrote:
> Hi,
> I have asked a question on stackoverflow about what I thought should be a
> relatively common scenario but I didn't get an answer even though I put a
> bounty on it and published it through my social networks to wide audience.
> Since it's still unanswered after a long time, I'm sending it here as a
> last hope for solution or expert insight.
>
>
> http://stackoverflow.com/questions/30253133/how-to-arrange-dependency-management-for-maven-reactor-if-child-modules-are-vers
>
> We have a reactor pom whose child modules are versioned independently, ie.
> child module declares it's own version that is independent of the version
> of the main pom. There is however a dependency between two child modules.
> How should be this dependency configured to always use the version that is
> declared by the actual module of the reactor pom?
>
> I would expect that I can set up dependency management in the root pom and
> use some implicit properties to determine the version of child modules, but
> the best such option I can find :
>
> ${session.projectDependencyGraph.sortedProjects[0].version}
>
> or simply
>
> ${reactorProjects[0].version}
>
> looks unreliable because the reactor order may change when new modules or
> dependencies are added.
>
More correctly what will happen when the poms are deployed into the
repository and are being consumed by a completely different reactor?
Once you start to reason about what happens when other projects outside the
reactor start to try and consume your modules you realize that the above
style of ${expression} references could never work.
The best you can rely on is properties in the current pom / parent pom /
(this one is evil) MAVEN_OPTS
And again those properties become problematic when resolving from the
repository
>
> Maybe this usage scenario is discouraged by design and then I would like to
> know why.
>
> As is suggested in comments in original stackoverflow post, declaring a
> global properties with child versions in parent POM may be an option for
> newer versions of Maven. I would however like to see some analysis with
> respect to wider consequences like workflow, releasing, directory and
> repository settings, some plugins usage (e.g. version plugin) etc. For
> example I think that direct consequence of this approach is that I would
> have to release parent module whenever any of child modules are released.
> Although this is doable, it would impact the original idea of having an
> independent versioning.
>
>
> --
> František
> http://calavera.info/
>
Re: How to arrange dependency management for maven reactor if child modules are versioned independently?
On 01/07/2015 12:29 PM, František Řezáč wrote: Your reasoning about the relationship between independent modules is right and made me think again really hard to formulate my intuitive disagreement. The important thing to notice is why a submodule is released. If it's because of some new, comprehensive feature set to be used in dependent modules that are part of the reactor, then your arguments are right an it should be expressed by changing the global parent. We are however releasing much more often because of external projects that depends on some submodule of the reactor pom. In fact we need to pin some version to the state of the submodule in some particular point in time so that external micro projects can release without releasing the whole platform. It sounds like you have to be prepared to support both reasons for releasing modules and to support the everyday building and testing of changes to individual modules. It may be helpful to think about the different versions of the parent POM. You need to track each revision that makes it into your SCM and make sure that versions are changed and that comments are added to the commit so that people can easily download the version that they need. The version of the parent POM on any individual workstation might be different from the versions in the SCM and people have to be careful about committing parent POMs to the SCM if they contain local changes - I might want to test Module A with my 1.2.4-SNAPSHOT of module B but you do not want me to commit that version of my parent POM to the SCM since it may not suit others who expect the master POM to have Module A depend on 1.2.3 of B until I finishing testing 1.2.4 and it is officially released. I am not sure why you want to link the modules together so tightly if they are really independent. We have a big project (a Learning Management System) with over 70 Maven projects, each with its own version (a lot share the same version as a bunch of other modules) and we build each one separately since most of the time only a few are being worked on during a release cycle. Release 1.2.4 might fix a set of bugs and add some enhancements but it only involves changes to 5 modules. We upgrade the version on the five modules to the same version number but actually code, test and release each one separately. When we make a change to a module that is a dependency for other modules, we have to change the version of the dependant module even if there is no code change. For example, if version of Module A is 1.2 and it depends on version 1.4 of module B and we are changing code in Module B to make version 1.5 of B, then we would change the pom of Module A to fix the dependency on B and change the version of Module A to 1.5. This might cause a repeat of the cycle if other modules depend on A. This way we have a repeatable build for the whole set of modules and can easily see that module A was affected by the 1.5 revision (even if it was only a POM change) We avoid peer dependencies but there are dependencies between layers so changes to persistence structures tend to bubble up through the stack. If you want to get a copy of everything as it was before 1.5 (ie the 1.4 release) , you can find all of the releases in our Nexus repo by selecting the highest release below 1.5 for each module (ie version 1.2 of Module A, version 1.4 of Module B, ... version 1.2.4 of Module XXX.) We use a spreadsheet to record and plan each new release and one of the planning tasks is to update the version plan to identify all of the new versions that will be created. This acts as a checklist for tasks to be done and helps us by identifying potential dependencies that frequently occur (changes to Module D potentially affects code in Module F, G and N) so over time we get better at estimating the impact of proposed enhancements. Ron So the release of submodule because of this reason is nothing significant from the point of view of the whole platform and all the internal dependencies should continue with the highest snapshot versions with as small effort as possible. I hope this does makes sense. František http://calavera.info Původní zpráva Od: Ron Wheeler Odesláno: středa, 1. července 2015 17:14 Komu: users@maven.apache.org Odpovědět: Maven Users List Předmět: Re: How to arrange dependency management for maven reactor if child modules are versioned independently? What is the relationship between the "independent" modules? If a child module gets a new version, should that trigger a change for other modules that depend on it? It seems to me from your description, that you do care when a child module releases a new version. If this should trigger a change in the dependant modules, then it seems reasonable that the parent pom should change to make this explicit. I would take a few seconds to think about how you want SNAPSHOTs to be handled. If A depends on B and B
Re: How to arrange dependency management for maven reactor if child modules are versioned independently?
Your reasoning about the relationship between independent modules is right and
made me think again really hard to formulate my intuitive disagreement.
The important thing to notice is why a submodule is released. If it's because
of some new, comprehensive feature set to be used in dependent modules that are
part of the reactor, then your arguments are right an it should be expressed by
changing the global parent. We are however releasing much more often because of
external projects that depends on some submodule of the reactor pom. In fact we
need to pin some version to the state of the submodule in some particular point
in time so that external micro projects can release without releasing the whole
platform.
So the release of submodule because of this reason is nothing significant from
the point of view of the whole platform and all the internal dependencies
should continue with the highest snapshot versions with as small effort as
possible. I hope this does makes sense.
František
http://calavera.info
Původní zpráva
Od: Ron Wheeler
Odesláno: středa, 1. července 2015 17:14
Komu: users@maven.apache.org
Odpovědět: Maven Users List
Předmět: Re: How to arrange dependency management for maven reactor if child
modules are versioned independently?
What is the relationship between the "independent" modules?
If a child module gets a new version, should that trigger a change for
other modules that depend on it?
It seems to me from your description, that you do care when a child
module releases a new version.
If this should trigger a change in the dependant modules, then it seems
reasonable that the parent pom should change to make this explicit.
I would take a few seconds to think about how you want SNAPSHOTs to be
handled.
If A depends on B and B goes from 1.2.3 to 1.2.4-SNAPSHOT, do you want A
to start to depend on the SNAPSHOT immediately or to continue to use
1.2.3 until 1.2.4 is released?
You may need to separate the dependency versions from the artifact
version if you want to keep A depending on the released version of B.
1.2.4-SNAPSHOT
1.2.3
This will also allow the developer of B to test the impact on module A
by setting B.current.release.version to 1.2.4-SNAPSHOT to build and test
A prior to releasing B.
Ron
On 01/07/2015 6:35 AM, František Řezáč wrote:
> Hi,
> I have asked a question on stackoverflow about what I thought should be a
> relatively common scenario but I didn't get an answer even though I put a
> bounty on it and published it through my social networks to wide audience.
> Since it's still unanswered after a long time, I'm sending it here as a
> last hope for solution or expert insight.
>
> http://stackoverflow.com/questions/30253133/how-to-arrange-dependency-management-for-maven-reactor-if-child-modules-are-vers
>
> We have a reactor pom whose child modules are versioned independently, ie.
> child module declares it's own version that is independent of the version
> of the main pom. There is however a dependency between two child modules.
> How should be this dependency configured to always use the version that is
> declared by the actual module of the reactor pom?
>
> I would expect that I can set up dependency management in the root pom and
> use some implicit properties to determine the version of child modules, but
> the best such option I can find :
>
> ${session.projectDependencyGraph.sortedProjects[0].version}
>
> or simply
>
> ${reactorProjects[0].version}
>
> looks unreliable because the reactor order may change when new modules or
> dependencies are added.
>
> Maybe this usage scenario is discouraged by design and then I would like to
> know why.
>
> As is suggested in comments in original stackoverflow post, declaring a
> global properties with child versions in parent POM may be an option for
> newer versions of Maven. I would however like to see some analysis with
> respect to wider consequences like workflow, releasing, directory and
> repository settings, some plugins usage (e.g. version plugin) etc. For
> example I think that direct consequence of this approach is that I would
> have to release parent module whenever any of child modules are released.
> Although this is doable, it would impact the original idea of having an
> independent versioning.
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to arrange dependency management for maven reactor if child modules are versioned independently?
What is the relationship between the "independent" modules?
If a child module gets a new version, should that trigger a change for
other modules that depend on it?
It seems to me from your description, that you do care when a child
module releases a new version.
If this should trigger a change in the dependant modules, then it seems
reasonable that the parent pom should change to make this explicit.
I would take a few seconds to think about how you want SNAPSHOTs to be
handled.
If A depends on B and B goes from 1.2.3 to 1.2.4-SNAPSHOT, do you want A
to start to depend on the SNAPSHOT immediately or to continue to use
1.2.3 until 1.2.4 is released?
You may need to separate the dependency versions from the artifact
version if you want to keep A depending on the released version of B.
1.2.4-SNAPSHOT
1.2.3
This will also allow the developer of B to test the impact on module A
by setting B.current.release.version to 1.2.4-SNAPSHOT to build and test
A prior to releasing B.
Ron
On 01/07/2015 6:35 AM, František Řezáč wrote:
Hi,
I have asked a question on stackoverflow about what I thought should be a
relatively common scenario but I didn't get an answer even though I put a
bounty on it and published it through my social networks to wide audience.
Since it's still unanswered after a long time, I'm sending it here as a
last hope for solution or expert insight.
http://stackoverflow.com/questions/30253133/how-to-arrange-dependency-management-for-maven-reactor-if-child-modules-are-vers
We have a reactor pom whose child modules are versioned independently, ie.
child module declares it's own version that is independent of the version
of the main pom. There is however a dependency between two child modules.
How should be this dependency configured to always use the version that is
declared by the actual module of the reactor pom?
I would expect that I can set up dependency management in the root pom and
use some implicit properties to determine the version of child modules, but
the best such option I can find :
${session.projectDependencyGraph.sortedProjects[0].version}
or simply
${reactorProjects[0].version}
looks unreliable because the reactor order may change when new modules or
dependencies are added.
Maybe this usage scenario is discouraged by design and then I would like to
know why.
As is suggested in comments in original stackoverflow post, declaring a
global properties with child versions in parent POM may be an option for
newer versions of Maven. I would however like to see some analysis with
respect to wider consequences like workflow, releasing, directory and
repository settings, some plugins usage (e.g. version plugin) etc. For
example I think that direct consequence of this approach is that I would
have to release parent module whenever any of child modules are released.
Although this is doable, it would impact the original idea of having an
independent versioning.
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
How to arrange dependency management for maven reactor if child modules are versioned independently?
Hi,
I have asked a question on stackoverflow about what I thought should be a
relatively common scenario but I didn't get an answer even though I put a
bounty on it and published it through my social networks to wide audience.
Since it's still unanswered after a long time, I'm sending it here as a
last hope for solution or expert insight.
http://stackoverflow.com/questions/30253133/how-to-arrange-dependency-management-for-maven-reactor-if-child-modules-are-vers
We have a reactor pom whose child modules are versioned independently, ie.
child module declares it's own version that is independent of the version
of the main pom. There is however a dependency between two child modules.
How should be this dependency configured to always use the version that is
declared by the actual module of the reactor pom?
I would expect that I can set up dependency management in the root pom and
use some implicit properties to determine the version of child modules, but
the best such option I can find :
${session.projectDependencyGraph.sortedProjects[0].version}
or simply
${reactorProjects[0].version}
looks unreliable because the reactor order may change when new modules or
dependencies are added.
Maybe this usage scenario is discouraged by design and then I would like to
know why.
As is suggested in comments in original stackoverflow post, declaring a
global properties with child versions in parent POM may be an option for
newer versions of Maven. I would however like to see some analysis with
respect to wider consequences like workflow, releasing, directory and
repository settings, some plugins usage (e.g. version plugin) etc. For
example I think that direct consequence of this approach is that I would
have to release parent module whenever any of child modules are released.
Although this is doable, it would impact the original idea of having an
independent versioning.
--
František
http://calavera.info/
