On Thu, 25 Jul 2013 18:08:40 +0200, Guy Gascoigne-Piggford
<g...@wyrdrune.com> wrote:
Our problem comes with first party dependencies. Pinning internally
developed libraries, and their consumers causes a horrible ripple of
version number changes for no reason other than to propagate the
dependencies. This gets expensive very quickly and we've got teams that
are understandably frustrated with this.
What are the numbers, I mean, how many ripple levels do you have? I'm
experiencing this only with a single project at a single customer, and
I've always blamed the fact that that project was born without Maven (or
any other modern dependency management facility), so it inherited some
legacy structure. Other projects, which involve mostly the same staff,
were born with Maven, but there's no frustration with them.
In any case, I've designed a workaround for the first case, even though I
don't like much and it's not perfect. The final assemble of the
application is done by a separated Maven project called "deployer" (I
reckon that "assembler" would be a better name, but that's it). It uses
the dependency maven plugin to retrieve the artifacts from the other
project modules. The deployer is composed of many sub-modules, each one
having its own declaration of versions; in this way, there is on
dependency divergence and the dependency resolving facility of Maven
doesn't kick in - I mean, you pick exactly the thing you need. So, if you
just need to upgrade the version of a module down in the dependency graph,
you just declare its explicit version.
This assumes that all the projects in the stack share the same versions of
external libraries - when we decide to upgrade any of them, this must
happen for the whole project.
This mimics the deploy process used before the mavenization (assemble was
done manually).
As I said, to me this is a project structure smell, so I'd first try to
understand whether there's something that can be improved in it.
--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to javaposse+unsubscr...@googlegroups.com.
To post to this group, send email to javaposse@googlegroups.com.
Visit this group at http://groups.google.com/group/javaposse.
For more options, visit https://groups.google.com/groups/opt_out.
