Hi,
The situation you describe look very similar to ours.
We use the maven release plugin.
but we had problems with versions:
warA has dep to jarB version 1 which has dep to jarC version1
warA has also dep to JarD version 1 which has dep to jarC version 2.
when warA is build, only version 1 of
> new jarB snapshot which causes things to break. How is that kind of thing
> best avoided (other than forcing down locked version numbers?)
COMMUNICATION is the key. As a general practice, don't check in things
that will break other people's stuff -- and if you must, do it in a
branch, then let p
You should discourage people from checking in things that will break
other people's releases.
Breaking libraries into smaller chunks that have more stable interfaces,
reduces the interference between developers.
Having a good interface specification for your libraries' APIs will make
your life
I'm not quite an expert on Maven, but would the Maven Release plugin help at
all?
http://maven.apache.org/plugins/maven-release-plugin/
I haven't used the plugin, so I can't speak to how well it works, but it
seems to me that should you be using a CI server to manage builds, when you
reach a succ
I've been trying to read up on best practices with Maven in a team
environment where different groups are working on different but related
modules. Been reading over chp7 of 'Better Builds With Maven' but still have
some questions.
To keep it simple for sake of discussion... war project depends o
