I believe using dependencyManagement actually helps you... it gives you
the power to control the dependency versions...
from the doc:
"very important use of the dependency management section is to control
the versions of artifacts used in transitive dependencies"
--zoly
Michael McCallum wrote:
Lets got back to the basics of development... you need to develop something to
that is delivered to be run....
So by my way of thinking I want an acurate description of whats delivered and
run such that I can reproduce it. Have the convention that versions are in
the jar names and the pom and its properties end up in the jar facilitates
this.
But I also need to have a flexible develoment environment with low overheads.
If I use best guess or open ranges I have no power to control things because
i need to tweak poms all over the place.
So my approach is a design and build by contract when i use the major version
to indicate a contract... and all my ranges restrict a dependency to a single
major version. e.g.
a.b.c-1.5 depends on a.b.d with [1,2)
This is arbitrarily simple see a more complex example attached
Now what this means is that when you break your project down into its
component pieces you can by convention relate them to other things stably.
Not reproducibly but thats ok because its determinable. If you try to build
your deliverable and there is a range conflict you get an error on build...
you can't build a dodgy deliverable.
With open version ranges or best guess deps you can end up with any released
dependency! and even if you have a process to know when you got it wrong but
its very difficult other than adding dependencies to the deliverable project
to get it right.
Now your developers need to make a call when they release - usually after
discussion - is my change breaking - you can test this with CI - and if so
should I increment the major version. If you get broken because they make a
mistake you have options... roll back deps... release a new rolled back
version...
The funny thing I avoided most of the gotches due to my approach...
Now the gotchas...
1) don't use modules
2) don't use snapshot parents or relative paths
3) inherit by function which means have parents that configure particular
plugins and keep them simple and try to have a little as possible in children
poms. i have a 2 deep hierarhcy with one root and 9 sub parents
The convention i use to break projects down is by function that means I have
api, model aka domain, strategy, composition, configuration, webapp, abstract
webapp, webservice, repository. It means a proliferation of artifacts but at
the same time a proliferation of reuse...
4) use a 2 point version major.release and always start at X.1 never at X.0
otherwise ranges don't work... its not a bug just an ideosyncracy... consider
[1,2) this does not match 1.0-SNAPSHOT and matches 2.0-SNAPSHOT which seems
odd... if you never make 1.0-SNAPSHOT or 2.0-SNAPSHOT then range boundaries
work determinably. range calculations break down if have more that 3 points
so you need to leave wiggle room.
5) save the third point for patches which are releases off branches
6) don't use dependency management it encourages bad inheritance, you can just
use transitive dependencies and they are more flexible
7) wrap 3rd party dependencies with local projects that just enforce
consistent resolution - they don't use ranges so you need to manage it
theres a taste i probably missed something as this is just off the top of my
head,
gotta do some work now
On Thu, 09 Oct 2008 12:47:13 Ian Robertson wrote:
On Sun, 2008-10-05 at 04:48 -0600, Michael McCallum wrote:
On Sat, 04 Oct 2008 14:16:57 Keith Branton wrote:
1. Can anyone please tell me of a way to achieve this with 2.0.9 today?
With the appropriate use of ranges you can do this and it resolves as
described. There are about 11 gotchas to doing it though, all worked
around by appropriate conventions.
Can you elaborate on what these 11 gotchas are, or point to a place
which does?
One of the biggest issues I see with ranges is that maven chooses the
most recent version in the repository which matches a given range.
Consequently, if a pom specifies a version range for a dependency like
[1.5,), the exact same code can create different builds on different
days if a new release of the dependency is made.
I'm actually curious if anyone knows the reason for this; it seams that
a far better choice would be to choose the *lowest* version which
matches all range requirements, so that builds could be temporally
stable.
- Ian
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
