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 <version>[2,3)</version> 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.
<properties>
<B.build.version>1.2.4-SNAPSHOT</B.build.version> <!-- version of B that
will be built -->
<B.current.release.version>1.2.3</B.current.release.version> <!--version
of B used to build A -->
</properties>
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
