On Fri, 12 Dec 2008 09:59:33 Chris Maki wrote:
When you say you get unstable builds you mean untested right? Because
appropriate use of ranges will prevent you
from assembling (war, ear, etc) artifacts that conflict.
Ultimately the goal is stable software... right?
In which case you want to use the version that you tested with for all the
libraries that
you depend upon.
Best practice says you isolate components and change to reduce the risk.
The simplest way of getting a consistent result with the scenario
com.foo:my-artifact:jar:1.0:compile
org.hibernate:hibernate:3.1.1:compile
com.foo:another-artifact:2.0:compile
org.hibernate:hibernate:3.1.3:compile
is to factor out the hibernate dependency (I've excluded the transitions of
hiberate composition here)
com.foo:my-artifact:jar:1.1-SNAPSHOT:compile
com.foo.composite:hibernate:[2,3):compile
com.foo:another-artifact:[2,3):compile
com.foo.composite:hibernate:[2,3):compile
where com.foo.composite:hibernate is defined as
com.foo.composite:hibernate:2.1
org.hibernate:hibernate:3.1.3:compile
Now if all of your projects that use hibernate are defined in terms of this
composite... then you KNOW which version of hibernate
and all the associated libraries you are going to get. And you manage the
lifecycle of the composite such that all minor releases don't
break anything using it (easier to test with CI). The composite lifecycle does
NOT need to match that of hibernate, so you can
have different artifacts that use older versions and maven will tell you that
you cannot package those two projects together.
~Michael
--
Michael McCallum
Enterprise Engineer
mailto:[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
