I also posted this question on stackoverflow, but I wanted to go "to
the source", as it were.
How should we manage the project and dependency versions in our POM
hierarchy? I apologize for the length of the message. The first
paragraph is probably all that's needed, but I'm not good at
self-editing and I wanted to give as much context as possible.
Scenario: The system has number of components, each with its own POM.
There are some long dependency chains (A depends on B depends on C,
etc.). I want each "non-developer-desktop" build to be a potential
release candidate -- if it passes QA, we will deploy it without
rebuilding. In other words, I never want to build SNAPSHOT versions as
part of my regularly scheduled builds, only versions like 1.3.0.5,
1.3.0.6, etc. I also want to enable the developers to work on multiple
components at once.
To forestall some expected suggestions: the Maven Release Plugin
doesn't help me ... unless there's some magic way I can have my
dependency versions not be SNAPSHOTs in the POMs but still let the
developers work on more than one component at once?
How should we manage the project and dependency versions in all of our
POMs? Right now it's just SNAPSHOTs everywhere, which makes things
simple for the developers (they started with SNAPSHOTs and never
concerned themselves with anything else). But it's worrying at
deployment time (builds with SNAPSHOT dependencies are not
well-defined, and not reproducible).
I'd like to avoid excessive version juggling at build time, but right
now I don't see any way around it.
Let's say I have components util, libj, libk, APP, and UI, with
dependencies as follows:
libj -> util (libj depends on util)
libk -> util
APP -> libj
UI -> libj, libk
I have development teams working on APP and UI, and they will
sometimes need to make changes/additions to some of the dependencies
(even util) in order to enable their current work. How should the
checked-in POM and dependency versions for each component look?
I'm prepared to hear that I may be taking the wrong approach to this
problem. All suggestions welcome.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
