Proper Dependency Management - HowTo?

[Peter Horlock]

Hi,

we got a software, which is devided into serveral sub projects.
We defined a parent pom, that, besides other shared items, contains a
dependency management section to ensure all sub projects are using the same
dependencies. Also, as the "software" we are talking about is actually a
website, there is never really something like a "final version" or so - the
product is constantly under development (with a monthly release cyclus).

Based on these preconditions, I figured out the following handling:
So far, we have the parent pom always as a SNAPSHOT version, and did not
differ between different versions of the parent pom.
So far, we have all dependencies - external as well as internal depdencies
(the sub projects themself) under dependency management.
When someone wants to change the version of a specific sub project, he does
so by editing a property in the parent pom
<mysubprojectXY-version>1.11</mysubprojectXY-version> which, on the basis of
this property, will then change the version in depdency management,
as well as the version of the sub project itself (and so keep them in sync).
This ensures all subprojects are ALWAYS using exactly the same dependencies
- external ones from other
suppliers, as well as internal ones provides by ourself.

However, the problem now is that when someone changes something in some sub
project, he could hardly ensure this change will not conflict with a certain
other sub project that might also use this project (and as so far we only
have one version of the parent pom, all projects will always get the latest
version of the parent pom, and so will also always get all updates from all
sub projects...)

1. Therefore, I suppose it was better if we were using different parent pom
versions, right?
In otherwords, if someone wants to change the version of a sub project, he
would also have to change the version of the parent pom, there he would
increment the version of the parent pom, as well as the version of the sub
project. When someone else wants to use the new paret pom, he would
deliberately change the parent pom he is using, and so he would know that he
had to check for version changes and their influences on his specific sub
project.

2. What about the version numbers of the sub projects?
a) Is it a good idea to have them entirely managed in the parent pom (by
using  a property, which is used in dependency management section, as well
as in the sub project version itself?), or
b) Is it a better idea to hard code the version of a sub project in its pom?


Based on the strength of past experience, I suppose it was best to use
different parent pom version for every release, and in between to maybe use
snapshot version, plus to keep up the process of having internal as well as
external dependencies in dep. management, and to keep the version in dep.
management with the last version of a certain sub project in sync by using
properties.

Do you agree? Or do you suggest another approach?

Thanks in advance,

Peter

[Michael McCallum-3]

Think about poms and dependendencies in the same way you would a piece of OO
code. You should use inheritance, composition and aggregation appropriately
to reduce change and improve stability. Don't make the mistake of thinking
that inheritance is the only solution.

On Tue, 01 Jul 2008 23:39:51 Peter Horlock wrote:

> Hi,
>
> we got a software, which is devided into serveral sub projects.
> We defined a parent pom, that, besides other shared items, contains a
> dependency management section to ensure all sub projects are using the same
> dependencies. Also, as the "software" we are talking about is actually a
> website, there is never really something like a "final version" or so - the
> product is constantly under development (with a monthly release cyclus).
>
> Based on these preconditions, I figured out the following handling:
> So far, we have the parent pom always as a SNAPSHOT version, and did not
> differ between different versions of the parent pom.
> So far, we have all dependencies - external as well as internal depdencies
> (the sub projects themself) under dependency management.
> When someone wants to change the version of a specific sub project, he does
> so by editing a property in the parent pom
> <mysubprojectXY-version>1.11</mysubprojectXY-version> which, on the basis
> of this property, will then change the version in depdency management, as
> well as the version of the sub project itself (and so keep them in sync).
> This ensures all subprojects are ALWAYS using exactly the same dependencies
> - external ones from other
> suppliers, as well as internal ones provides by ourself.
>
> However, the problem now is that when someone changes something in some sub
> project, he could hardly ensure this change will not conflict with a
> certain other sub project that might also use this project (and as so far
> we only have one version of the parent pom, all projects will always get
> the latest version of the parent pom, and so will also always get all
> updates from all sub projects...)
>
> 1. Therefore, I suppose it was better if we were using different parent pom
> versions, right?
> In otherwords, if someone wants to change the version of a sub project, he
> would also have to change the version of the parent pom, there he would
> increment the version of the parent pom, as well as the version of the sub
> project. When someone else wants to use the new paret pom, he would
> deliberately change the parent pom he is using, and so he would know that
> he had to check for version changes and their influences on his specific
> sub project.
>
> 2. What about the version numbers of the sub projects?
> a) Is it a good idea to have them entirely managed in the parent pom (by
> using  a property, which is used in dependency management section, as well
> as in the sub project version itself?), or
> b) Is it a better idea to hard code the version of a sub project in its
> pom?
>
>
> Based on the strength of past experience, I suppose it was best to use
> different parent pom version for every release, and in between to maybe use
> snapshot version, plus to keep up the process of having internal as well as
> external dependencies in dep. management, and to keep the version in dep.
> management with the last version of a certain sub project in sync by using
> properties.
>
> Do you agree? Or do you suggest another approach?
>
> Thanks in advance,
>
> Peter

--
Michael McCallum
Enterprise Engineer
mailto:gholam@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Peter Horlock]

Could you be a bit more precise? (Just make it plain simple, this increases
the chance that I get it! ;-)

Thanks,

Peter

[Michael McCallum-3]

On Thu, 03 Jul 2008 00:44:20 Peter Horlock wrote:
> Could you be a bit more precise? (Just make it plain simple, this increases
> the chance that I get it! ;-)
I suppose

The things i do
1) parent version are always release versions

2) all depedencies are always release versions

3) release often

4) use version ranges to manage the contracts
e.g.
project.api = 1.x
project.implementation uses api.[1,2-!)
project.consumer uses api.[1,2-!)
project.deployable uses implementation.[1,2-!) and consumer.[1,2-!)
obviously in the real world things aren't this simple and for simple cases
this seems like excessive overhead

5) when ever you make a breaking change increment the major version

6) start version numbering 1.1 for new artifacts
 * makes ranges work better
 * who needs the extra .0 on the end, i save that for patches

7) in order to integrate 3p libraries i create a wrapping pom which follows
the above version rules
e.g.
for hibernate i have
hibernate.composite 7.x uses hibernate 3.2.6ga, uses ehcache 3.0, uses
cglib... excludes commons-logging, excludes ehcache, excludes cglib-full
and all my projects the use hibernate use hibernate.composite.[7,8-!)
8) use mvn dependency:resolve and mvn depedendency:tree regularly to
understand how things are working and to catch any transitions that i did not
expect
9) set up aliases
alias mvnsrc='mvn dependency:sources'
alias mvntag='mvn release:prepare -Penforce-no-snapshots'
alias mvntree='mvn dependency:tree'
alias mvnup='mvn release:perform -Dgoals=deploy'
alias mvndep='mvn dependency:resolve'
10) use the enforcer to ensure releases don't contain snapshots make sure to
traverse transitions
11) don't mix inheritance and aggregation. that means a parent pom NEVER ever
has modules, if you think about the concept for a minute - or longer - there
will be a moment of enlightenment
12) set up parents that define plugins for particular types of projects i.e.
webapps, jars, parents,
13) define repositories in settings.xml, been meaning patch the settings
resolver to load profiles from a directory so that i can source control the
repositories for different projects independency
14) keep all artifacts granular to simplify resolution trees and isolate
change
15) use the m2eclipse plugin so that deps work properly (or equivalent plugin
for other ide of choice)
16) DONT use the same output folders for eclipse and for maven as eclipse
instruments classes and it will break things
17) regularly refactor at the artifact level not just code level

Simple enough? I might diverge from common practise in some places but I'm
pretty sure from watching the lists that I have way fewer problems as a
result ;-)

--
Michael McCallum
Enterprise Engineer
mailto:gholam@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Peter Horlock]

2008/7/3 Michael McCallum <gholam@...>:

> On Thu, 03 Jul 2008 00:44:20 Peter Horlock wrote:
> > Could you be a bit more precise? (Just make it plain simple, this
> increases
> > the chance that I get it! ;-)
> I suppose
>
> The things i do
> 1) parent version are always release versions

2) all depedencies are always release versions

Why no snapshots?!  In our company, often many people are working on the
same projects, e.g. that contains shared, "common" classes -
So it can happen that there will be 3 different "versions" in a single
day...


>
> 4) use version ranges to manage the contracts
> e.g.
> project.api = 1.x
> project.implementation uses api.[1,2-!)
> project.consumer uses api.[1,2-!)
> project.deployable uses implementation.[1,2-!) and consumer.[1,2-!)


I don't know much about version ranges yet. Why should I use them?! I
Unfortunately the maven docu doesn't say may about version ranges either,
but I've read this:
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
However, nothing's said about the "!" Syntax you are using. Anyway, I
suppose you want to say "use a version between 1 and 2".
But then you might get a newer version, were some colleague has changed
something which might break your build. ???


> > when ever you make a breaking change increment the major version


In  our case, this is hardly ever the case. Iterative development, Little
steps by steps...

>
>
> 7) in order to integrate 3p libraries i create a wrapping pom which follows
> the above version rules
> e.g.
> for hibernate i have
> hibernate.composite 7.x uses hibernate 3.2.6ga, uses ehcache 3.0, uses
> cglib... excludes commons-logging, excludes ehcache, excludes cglib-full
> and all my projects the use hibernate use hibernate.composite.[7,8-!)


You mean for external dependencies, like hibernate, that do not provide a
pom by themself, you create a pom yourself, I asume.
Why do you exclude dependencies? I mean if some dep. has a transitive dep.,
it could happen that someday you will actually need this transitive dep. -
and then it wouldn't hurt to have it, would it? On the other hand, having a
jar that is just a bit bigger with dep. not currently used, doesn't hurt
either, does it???


> 8) use mvn dependency:resolve and mvn depedendency:tree regularly to
> understand how things are working and to catch any transitions that i did
> not
> expect


Are you using dependency:analyze<http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html>?
I tried it, but often it declars jars as "not used but declared", but
when
I remove them, the project will fail at runtime or so, on the oher hand
"used but not declared" often
declares jars I really don't need... I don't really get it...


> 9) set up aliases
> alias mvnsrc='mvn dependency:sources'
> alias mvntag='mvn release:prepare -Penforce-no-snapshots'
> alias mvntree='mvn dependency:tree'
> alias mvnup='mvn release:perform -Dgoals=deploy'
> alias mvndep='mvn dependency:resolve'


That must be unix / linux, I suppose.

>
> 11) don't mix inheritance and aggregation. that means a parent pom NEVER
> ever
> has modules, if you think about the concept for a minute - or longer -
> there
> will be a moment of enlightenment


Nope, don't get it. We have all our sub projects in our parent pom. Before,
we had the parent pom and a separate module pom - this makes things so much
more complicated -
you have to install, deploy... two poms instead of one. Also, if you just
want to install, deploy... the parent pom itself without the modules, you
can use the "-N" flag.
Or did I miss something???


>
> >use the m2eclipse plugin so that deps work properly (or equivalent plugin
> for other ide of choice)


Yeah, m2eclipse plugin's nice, however, it doesn't support Eclipse 3.4 yet!
:-(

>
> > regularly refactor at the artifact level not just code level

Can you explain that in more detail?

>
> >Simple enough?


Much better, but I could stilll use some enlightment! :-)
Also, I feel, even though you gave me LOTS of good tips and tweaks, you
didn't really answer my question(s) - which was:
1. Use one and the same parent pom with "snapshot" as version nummer, or
have different versions of the parent pom? I guess from what you wrote,
different versions
2. Subprojects - version number directly in the project pom itself, or is it
a good idea to have a property value for each sub project version in the
parent pom, and so
to keep the version in dependency management in sync with the most recent
version of each current sub project version.

Thanks a lot,

Peter

[Jörg Schaible]

Hi Michael,

well it seems everybody has some different scheme that works for him/his company.

Michael McCallum wrote:
> On Thu, 03 Jul 2008 00:44:20 Peter Horlock wrote:
>> Could you be a bit more precise? (Just make it plain simple, this
>> increases the chance that I get it! ;-)
> I suppose
>
> The things i do
> 1) parent version are always release versions

We use always SNAPSHOT (not even a version), therefore all components can rever the latest parent (we have a global one for our company defining all arofact versions in the dependencyManagement).

> 2) all depedencies are always release versions

If somebody works on a component, we use SNAPSHOT-version and set this also in the parent POM. That reflects a change in the "core" component. All artifacts that are dependent on this should use the SNAPSHOT parent and therefore will use automatically the latest version (well, this policy depends actually on the project)

> 3) release often

We release in "waves". If a major component/product has to be released, we adjust the depMgmt in the global POM with the upcoming released versions and release the global POM (after the release the global POM is set back to SNAPSHOT immediately). Then each of those artifacts is released also using the version of the just released global POM:

> 4) use version ranges to manage the contracts
> e.g.
> project.api = 1.x
> project.implementation uses api.[1,2-!)
> project.consumer uses api.[1,2-!)
> project.deployable uses implementation.[1,2-!) and consumer.[1,2-!)
> obviously in the real world things aren't this simple and for
> simple cases
> this seems like excessive overhead

We do not use ranges at all. Works great without.

> 5) when ever you make a breaking change increment the major version
>
> 6) start version numbering 1.1 for new artifacts
>  * makes ranges work better
>  * who needs the extra .0 on the end, i save that for patches

Why's that? Also remember that version 1 is implicitly 1.0.0.0 ;-)
 

> 7) in order to integrate 3p libraries i create a wrapping pom
> which follows
> the above version rules
> e.g.
> for hibernate i have
> hibernate.composite 7.x uses hibernate 3.2.6ga, uses ehcache
> 3.0, uses
> cglib... excludes commons-logging, excludes ehcache, excludes
> cglib-full and all my projects the use hibernate use
> hibernate.composite.[7,8-!)

We make these adjustments directly in the depMgmnt of the global POM.

> 8) use mvn dependency:resolve and mvn
> depedendency:tree regularly to understand how things are working and
> to catch any
> transitions that i did not
> expect

Especially after upgrading version of 3rd party artifacts ;-)

> 9) set up aliases
> alias mvnsrc='mvn dependency:sources'
> alias mvntag='mvn release:prepare -Penforce-no-snapshots'
> alias mvntree='mvn dependency:tree'
> alias mvnup='mvn release:perform -Dgoals=deploy'
> alias mvndep='mvn dependency:resolve'

Hehehe, we use bash functions:

function mc() { mvn $* clean || echo -e "\a"; }
function mi() { mvn $* install || echo -e "\a"; }
function mci() { mvn $* clean install || echo -e "\a"; }
function mcmi() { mvn $* clean && mvn $* install || echo -e "\a"; }
function me() { mvn $* eclipse:eclipse || echo -e "\a"; }
function mce() { mvn $* eclipse:clean eclipse:eclipse || echo -e "\a"; }

> 10) use the enforcer to ensure releases don't contain
> snapshots make sure to
> traverse transitions
> 11) don't mix inheritance and aggregation. that means a
> parent pom NEVER ever
> has modules, if you think about the concept for a minute - or
> longer - there
> will be a moment of enlightenment

+1

> 12) set up parents that define plugins for particular types
> of projects i.e.
> webapps, jars, parents,

We setup the common settings in the pluginMgmnt of the global POM ... and lock down the plugin versions.

> 13) define repositories in settings.xml, been meaning patch
> the settings
> resolver to load profiles from a directory so that i can
> source control the
> repositories for different projects independency

+1

> 14) keep all artifacts granular to simplify resolution trees
> and isolate
> change

+1

> 15) use the m2eclipse plugin so that deps work properly (or
> equivalent plugin for other ide of choice)

We use the normal maven eclipse plugin to generate the projects, no need for m2eclipse.

> 16) DONT use the same output folders for eclipse and for
> maven as eclipse
> instruments classes and it will break things

I use the same folders without problems.

> 17) regularly refactor at the artifact level not just code level
>
> Simple enough? I might diverge from common practise in some
> places but I'm
> pretty sure from watching the lists that I have way fewer
> problems as a
> result ;-)

We also :)

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Michael McCallum-3]

> > The things i do
> > 1) parent version are always release versions
>
> 2) all depedencies are always release versions
>
> Why no snapshots?!  In our company, often many people are working on the
> same projects, e.g. that contains shared, "common" classes -
> So it can happen that there will be 3 different "versions" in a single
> day...
To give you a perspective we have 9 deliverables with more that 140 artifacts.
Many of those artifacts are shared at various levels between components
assembled in the deliverables.

a) Well deployed snapshots generally cause more trouble than they are worth.
b) I find that can be true on some days but usually find thats because the
code layout is wrong or that it will stabilise after a few days
c) i've made it really fast and easy to release, with ranges i pick up the
next increment without having to snapshot, it means the other developer ran
the tests and was confident (s)he was finished his task properly
d) we must release 15 to 20 artifacts per day and at least one deliverable
obviously not all of those end up in releases (murphys law the last one you
build gets in)
e) with snapshots I lose the control

>
> > 4) use version ranges to manage the contracts
> I don't know much about version ranges yet. Why should I use them?! I
Simple mathematical ranges i use [x,y-!) which is greater than or equal to x
and less than y where y includes -SNAPSHOT, -alpha etc

Without the -! the range [1,2) would match 2-SNAPSHOT or 2.0.0-SNAPSHOT which
is obviously not the intention. Its simply a side effect of 2-SNAPSHOT < 2.

> But then you might get a newer version, were some colleague has changed
> something which might break your build. ???
indeed which is why you communicate, you have the same problem with snapshots,
source depedencies etc etc. However with ranges if you do break and you don't
have the time to fix it you can just do [1,1.5-!) where the version which
breaks is 1.5 and now you are building until you fix your problem or push
back on the other person to fix theirs... 2 seconds work...

>
> > > when ever you make a breaking change increment the major version
>
> In  our case, this is hardly ever the case. Iterative development, Little
> steps by steps...
we do exactly the same thing, but the view I take is what can the deliverables
see... take a pragmatic approach sometime its ok to break lots of things...
sometimes its not you need to make a call

isolating api projects helps here as you can have many things depedent upon
the api and isolate the breakages

>
> > 7) in order to integrate 3p libraries i create a wrapping pom which
> > follows the above version rules
> > e.g.
> > for hibernate i have
> > hibernate.composite 7.x uses hibernate 3.2.6ga, uses ehcache 3.0, uses
> > cglib... excludes commons-logging, excludes ehcache, excludes cglib-full
> > and all my projects the use hibernate use hibernate.composite.[7,8-!)
>
> You mean for external dependencies, like hibernate, that do not provide a
> pom by themself, you create a pom yourself, I asume.
> Why do you exclude dependencies? I mean if some dep. has a transitive dep.,
> it could happen that someday you will actually need this transitive dep. -
> and then it wouldn't hurt to have it, would it? On the other hand, having a
> jar that is just a bit bigger with dep. not currently used, doesn't hurt
> either, does it???

I exclude dependencies that either
a) should not be there which is common for ant based projects with have no
transitive resolution
b) i want a different version of the library which i have composed somewhere
else to be consistent across all my resolution trees
c) i want to get rid of the commons-logging pox, i prefer slf4j

>
> Are you using
> dependency:analyze<http://maven.apache.org/plugins/maven-dependency-plugin/
no that was intended really to fix deps before some core changes from 2.0.5 to
2.06 or something
>
> > 9) set up aliases
> > alias mvnsrc='mvn dependency:sources'
> That must be unix / linux, I suppose.
yes you can do the same with batch files on windows... best thing you could
ever do

>
> > 11) don't mix inheritance and aggregation. that means a parent pom NEVER
> > ever
> > has modules, if you think about the concept for a minute - or longer -
> > there
> > will be a moment of enlightenment
>
> Nope, don't get it. We have all our sub projects in our parent pom. Before,
> we had the parent pom and a separate module pom - this makes things so much
> more complicated -
> you have to install, deploy... two poms instead of one. Also, if you just
> want to install, deploy... the parent pom itself without the modules, you
> can use the "-N" flag.
> Or did I miss something???

i have 8 parent poms - root, jar, webapp, service, model etc etc
the parent pom defines distribution management, scms, and plugins for specific
functions

all dependencies are managed by composition not inheritance, change parents
all the time sucks however with ranges and composition its easy for example
for me to upgrade all the various projects to use hibernate 3.2.6ga from
3.2.5ga with one or two releases and then rebuilding the deliverables...

unless of course 3.2.6ga breaks things in which case i might increment the
major version of the composition... and upgrade one resolution tree at a time

>
> > >use the m2eclipse plugin so that deps work properly (or equivalent
> > > plugin
> >
> > for other ide of choice)
>
> Yeah, m2eclipse plugin's nice, however, it doesn't support Eclipse 3.4 yet!
you should downgrade eclipse or patch the plugin... one key things is that
when developing lots of disparate artifacts you can install the snapshot for
each and the plugin will magically associate them in eclipse... that way you
can have refactorings apply across all your projects at once

one major GOTCHA to eclipse is that it merges the different scopes i.e. test
and compile are indistiguishable, just means you should double check things
on the command line...

one other major GOTCHA is that eclipse and some plugin combinations on windows
will lock your pom when you try to release and break the release half way
through. The pain of exclusive read locks!

>
> :-(
> :
> > > regularly refactor at the artifact level not just code level
>
> Can you explain that in more detail?
Yes you can do what i call artifactoring which bears some parallels to
enterprise patterns.

I am doing a presentation at the Auckland JUG in august and will post details
here soon.

>
> > >Simple enough?
>
> 1. Use one and the same parent pom with "snapshot" as version nummer, or
> have different versions of the parent pom? I guess from what you wrote,
> different versions
different versions, people get too hung up on artifact version but ultimately
only the deliverable versions have meaning outside the dev team, just like
revision numbers in source control don't matter as long as the pattern is
consistent and decipherable. Ranges let you be really specific about what any
project means. Using the hit and hope version def basically means you project
can end up looking like anything.

> 2. Subprojects - version number directly in the project pom itself, or is
> it a good idea to have a property value for each sub project version in the
> parent pom, and so
> to keep the version in dependency management in sync with the most recent
> version of each current sub project version.
I would keep it simple. My motto is each artifact should build in isolation
when checked out. Property interpolation from parents causes all sorts of
issues. So I always have a version in an artifact, the version for the
artifact is for the artifact and not for any group of projects.

If you try to enforce an arbitraty version lifecycle on many artifacts in a
group where do you stop? do you just have one version? I think each artifact
is better served with its own... it has its own deps, its own docs, its own
tests it should have its own version. This also means projects all start
looking the same.

my standard layout is
x
y
z
modules - which includes x, y and z as modules for testing and documentation

I find with granular artifacts that the interative churn is isolated into a
few artifacts at a time. Over time you can isolate the unstable artifacts,
these tend to end up with large major versions ;-) Often splitting them in
two reduces the churn.

>
> Thanks a lot,
Welcome

--
Michael McCallum
Enterprise Engineer
mailto:gholam@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Michael McCallum-3]

On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote:
> > 6) start version numbering 1.1 for new artifacts
> >  * makes ranges work better
> >  * who needs the extra .0 on the end, i save that for patches
>
> Why's that? Also remember that version 1 is implicitly 1.0.0.0
so that range [1,2-!) does includes 1.1-SNAPSHOT if i happen to install as a
snapshot which is pretty common for a 1.1 version of an artifacts

Because there is no need to label things 1.0.0. ... 1.0 is sufficient.

When looking at any of the deliverables I produce you can tell immediately if
it was a release or a patch by seeing 1.X, 2.X where as a patch would be
1.3.1.



--
Michael McCallum
Enterprise Engineer
mailto:gholam@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Michael McCallum-3]

On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote:
> > project.deployable uses implementation.[1,2-!) and consumer.[1,2-!)
> > obviously in the real world things aren't this simple and for
> > simple cases
> > this seems like excessive overhead
>
> We do not use ranges at all. Works great without.

Define great... You have no real definition of a build... its transient as
saying i would like something that kinda resembles 3.4.5 of an artifacts does
not really mean much at the end of the day. It would be possible for maven to
resolve 2.0.5. (just look at our xml apis/xerces versions in dependency:tree)

where as saying i can only use any 1.X version of an artifact is a lot more
constraining. I would never get a deliverable which had version 3, or 2 etc.

For the same reason that static type checking is good so are ranges.

--
Michael McCallum
Enterprise Engineer
mailto:gholam@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Michael McCallum-3]

On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote:
> > hibernate.composite 7.x uses hibernate 3.2.6ga, uses ehcache
> > 3.0, uses
> > cglib... excludes commons-logging, excludes ehcache, excludes
> > cglib-full and all my projects the use hibernate use
> > hibernate.composite.[7,8-!)
>
> We make these adjustments directly in the depMgmnt of the global POM.
which means you have to release from the top down.

I can release any artifact any time... i live on the ready to release to
production rather than beginning of build cycle line. Subtle but fundamental
difference. And the overhead is minimal.


--
Michael McCallum
Enterprise Engineer
mailto:gholam@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Michael McCallum-4]

On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote:
> > 8) use mvn dependency:resolve and mvn
> > depedendency:tree regularly to understand how things are working and
> > to catch any
> > transitions that i did not
> > expect
>
> Especially after upgrading version of 3rd party artifacts ;-)

Actually that is _never_ a problem for me because I compose 3rd party
artifacts into a separate pom thats the only place the deps can go wrong.
When i upgrade the 3p library I isolate and control the depedencies in the
composition. I can therefore guarantee that the dependency tree is no
different than before or I can bump the major version to identify that the
contract (i.e. same dep tree) is broken.

--
Michael McCallum
Development Lead
Ferrit Ltd
cell: 021.576.907
msn: gholam@...
jabber: mccallum.michael@...
aim: gholamses
http://www.ferrit.co.nz

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Michael McCallum-3]

On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote:
> > 12) set up parents that define plugins for particular types
> > of projects i.e.
> > webapps, jars, parents,
>
> We setup the common settings in the pluginMgmnt of the global POM ... and
> lock down the plugin versions.
 not quite what i was getting at, my point was that plugin configurations tend
to be common across function not group

a common anti pattern in poms is to have

company.pom
-> group.pom
 -> model
 -> service
 -> war

http://www.codinghorror.com/blog/archives/000589.html

now repeat that pattern for 9 deliverables and you get "Duplicated Code"

the plugin configuration either goes into company.pom "Large Class" or you
have to refactor the inheritance  to work by function

company.parent
-> jar.parent
-> model.parent

group/
  model :: model.parent
  service :: service.parent
 
You wil note things like this... cobertura branch/coverage constraints are
different for services and models.

The overhead of putting things in the company pom is that you need to change
all the projects to the new version OR you can use snapshots and make it a
major overhead to start a release cycle


--
Michael McCallum
Enterprise Engineer
mailto:gholam@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Michael McCallum-3]

On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote:
> > 8) use mvn dependency:resolve and mvn
> > depedendency:tree regularly to understand how things are working and
> > to catch any
> > transitions that i did not
> > expect
>
> Especially after upgrading version of 3rd party artifacts ;-)

Actually that is _never_ a problem for me because I compose 3rd party
artifacts into a separate pom thats the only place the deps can go wrong.
When i upgrade the 3p library I isolate and control the depedencies in the
composition. I can therefore guarantee that the dependency tree is no
different than before or I can bump the major version to identify that the
contract (i.e. same dep tree) is broken.

--
Michael McCallum
Enterprise Engineer
mailto:gholam@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jörg Schaible]

Michael McCallum wrote:

> On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote:
>>> project.deployable uses implementation.[1,2-!) and consumer.[1,2-!)
>>> obviously in the real world things aren't this simple and for
>>> simple cases this seems like excessive overhead
>>
>> We do not use ranges at all. Works great without.
>
> Define great... You have no real definition of a build... its
> transient as saying i would like something that kinda resembles 3.4.5
> of
> an artifacts does
> not really mean much at the end of the day. It would be
> possible for maven to
> resolve 2.0.5. (just look at our xml apis/xerces versions in
> dependency:tree)

This is not true. Since we define the version (no range) in the depMgmnt, this will superceed also the inherited versions and Maven has not really to do any version resolution.
 
> where as saying i can only use any 1.X version of an artifact
> is a lot more
> constraining. I would never get a deliverable which had
> version 3, or 2 etc.

What do I have from the range definition at all? If I build two EJBs and one refers commons-collections 3.1 and the other one commons-collections 3.1.1 in its manifest's class path, the resulting EAR is broken since one EJB is referencing a not available jar. It does not help me that both EJB can run with both versions of commons-collection. Without the range I will get either 3.1 or 3.1.1 - depending on what I selected in the global master pom.

> For the same reason that static type checking is good so are ranges.

If it does not resolve to the same artifact inthe end, it will help you nothing.

- Jörg



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jörg Schaible]

Michael McCallum wrote:

> On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote:
>>> hibernate.composite 7.x uses hibernate 3.2.6ga, uses ehcache
>>> 3.0, uses
>>> cglib... excludes commons-logging, excludes ehcache, excludes
>>> cglib-full and all my projects the use hibernate use
>>> hibernate.composite.[7,8-!)
>>
>> We make these adjustments directly in the depMgmnt of the
> global POM.
> which means you have to release from the top down.
>
> I can release any artifact any time... i live on the ready to release
> to production rather than beginning of build cycle line. Subtle but
> fundamental difference. And the overhead is minimal.

The overhead is that you produce a lot of versions that may live for just a view ours and that will not be of any use later.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jörg Schaible]

Michael McCallum wrote:

> On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote:
>>> 12) set up parents that define plugins for particular types of
>>> projects i.e. webapps, jars, parents,
>>
>> We setup the common settings in the pluginMgmnt of the global POM
>> ... and lock down the plugin versions.
>  not quite what i was getting at, my point was that plugin
> configurations tend to be common across function not group
>
> a common anti pattern in poms is to have
>
> company.pom
> -> group.pom
>  -> model
>  -> service
>  -> war
>
> http://www.codinghorror.com/blog/archives/000589.html
>
> now repeat that pattern for 9 deliverables and you get "Duplicated
> Code"

Sorry, but our priority is to ensure that all artifacts are built with the same plugins and use the same artifact versions. In your model I have to duplicate all the versions for your individual service parents. That's what I call an anti-pattern. No, thanks, we've already bitten enough by that.

> the plugin configuration either goes into company.pom "Large Class"
> or you have to refactor the inheritance  to work by function
>
> company.parent
> -> jar.parent
> -> model.parent
>
> group/
>   model :: model.parent
>   service :: service.parent
>
> You wil note things like this... cobertura branch/coverage
> constraints are different for services and models.

All kind of "individual" plugin configuration tend to be really "individual". As long as Maven does not support to reuse certain POM sections (like it is now available with scope import at least for the depMgmnt), you will not be able to avoid some duplication in the POMs.

> The overhead of putting things in the company pom is that you need to
> change all the projects to the new version OR you can use snapshots
> and make it a major overhead to start a release cycle

It depends on your development model. We do the second and it works well.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jörg Schaible]

Michael McCallum wrote:

> On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote:
>>> 6) start version numbering 1.1 for new artifacts
>>>  * makes ranges work better
>>>  * who needs the extra .0 on the end, i save that for patches
>>
>> Why's that? Also remember that version 1 is implicitly 1.0.0.0
> so that range [1,2-!) does includes 1.1-SNAPSHOT if i happen
> to install as a
> snapshot which is pretty common for a 1.1 version of an artifacts
>
> Because there is no need to label things 1.0.0. ... 1.0 is sufficient.

From Maven's PoV 1 is sufficient.

> When looking at any of the deliverables I produce you can
> tell immediately if
> it was a release or a patch by seeing 1.X, 2.X where as a
> patch would be
> 1.3.1.

There's no difference in the end. I see the same.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Peter Horlock]

The problem I see with version ranges, is you start loosing control.
I guess the vital part to make the use of version ranges work (at all) is
that every developer has to follow the rule

major.minor.patch...

So far, we have been very loose with versions - Someone changes 5 lines in
the code, makes a new (patch) version, someone else changes another 7 lines,
makes another (patch) version, and so on - we keep on "patching" the jar -
1.3.57 - I wonder when we will hit a hundred or a thousand! ;-)

So I guess if EVERY developer would only use the "patch section" if it was
really just a minor patch that will not influence anything really, but would
use the minor or major section for all other changes, ranges might work
without breaking other ppls builds - but this mechanismus counts on this
very ability, which is hard to maintain, especially with new developers
joining the team. When you have strict versions everyone has to change to a
new version deliberately.

About the thing with version numbers as property values in the parent pom -
I am still not sure this is the best way, especially not with project that
are not really shared by others,
but this is the easiest way to update the dependency management section -
otherwise, when someone changes the version of a submodule, one has to
change this version, as well as the version in dep. mgmt.

Hmmmm, this is really hard to swallow, I can't really find THE one and only
solution of how to solve this dilemma - well, maybe I am still missing
something?

Peter

[Peter Horlock]

2008/7/3 Jörg Schaible <Joerg.Schaible@...>:

> Sorry, but our priority is to ensure that all artifacts are built with the
> same plugins and use the same artifact versions. In your model I have to
> duplicate all the versions for your individual service parents. That's what
> I call an anti-pattern. No, thanks, we've already bitten enough by that.


I am not sure if I properly got your point, but I also think that using
version ranges and no proper dep. mgmt will lead to using different
submodule version in the same project. We had that with Maven 1, and wasn't
that one of the main reasons for Maven 2? The dep mgmt makes using dep. more
strict - it allows you to exactly nail down one version all other sub
modules are sharing among each other - if, in the rare case, that there is a
sub project that does need to violate this rule and has to use an older /
newer version of a dep., you may do so by overiding its version number.

Not sure if I got it right, but imho that was Michaels point, using version
ranges and so...

[Jörg Schaible]

Hi Peter,

Peter Horlock wrote:

> The problem I see with version ranges, is you start loosing control.
> I guess the vital part to make the use of version ranges work (at
> all) is that every developer has to follow the rule
>
> major.minor.patch...
>
> So far, we have been very loose with versions - Someone
> changes 5 lines in
> the code, makes a new (patch) version, someone else changes
> another 7 lines,
> makes another (patch) version, and so on - we keep on "patching" the
> jar -
> 1.3.57 - I wonder when we will hit a hundred or a thousand! ;-)
>
> So I guess if EVERY developer would only use the "patch
> section" if it was
> really just a minor patch that will not influence anything
> really, but would
> use the minor or major section for all other changes, ranges
> might work
> without breaking other ppls builds - but this mechanismus
> counts on this
> very ability, which is hard to maintain, especially with new
> developers joining the team. When you have strict versions everyone
> has
> to change to a
> new version deliberately.
>
> About the thing with version numbers as property values in
> the parent pom -
> I am still not sure this is the best way, especially not with
> project that
> are not really shared by others,
> but this is the easiest way to update the dependency
> management section -
> otherwise, when someone changes the version of a submodule, one has to
> change this version, as well as the version in dep. mgmt.

Neither Michael nor I did propose properties for the version. Simply define the version in the version depMgmnt itself and you're done.

> Hmmmm, this is really hard to swallow, I can't really find
> THE one and only
> solution of how to solve this dilemma - well, maybe I am still
> missing something?

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...