maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maczka Michal <michal.mac...@imtf.ch>
Subject RE: dependencies in reactorized builds
Date Mon, 31 Jan 2005 11:55:52 GMT


> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: Monday, January 31, 2005 12:13 PM
> To: Maven 2 Developers List
> Subject: Re: dependencies in reactorized builds
> 

> But I don't think we should come to reliance on a tool to do 
> this either 
> if there is a practical and logical way to share the information.
> 
> >d) (MAIN ISSUE) Project inheritance leads to yet another 
> dependency. If we
> >are going to change a 
> >  
> >
> As above, I agree we need to sort out how this will work in practice, 
> but I think it needs to be easier to deal with than changing 
> everywhere.
> 

It is an admirable goal but I am afraid it is impossible to achive in the
pratice.
I see it like that:
To preserv the reproductaibility there is a simple rule to follow: 
Everytime you change something in the project (directly or indirectly) you
are _changing_ that project.
so you have to increase its version number.
So if you change a dependecy version in a "common pool" - if it affects
given project 
you have to edit the pom and bump the version number. 
In case of the solution which was decribed by John it may require to change
long chain of projects
(chain is defined by parent-child relation)


One more remark (off topic):

There is a horrible practice currently in common use:

People are not realy paying attentions to version numbers.
Say there you are using hibernate version 2.1.8. It has a dependecy on
common-collectiions-2.11
It means that hiberante team has tested their version of hibernate agaist
common-collectiions-2.11. 
There is abolutly no gurantee that it will work with any other version of
common-collections, yet you will see many people
using hibernate with web frameworks like struts or spring which are using
different version of that jar.
We can do nothing about it - but the whole idea that you can randomly
replace or define jar which you are willing to
use when you are reusing liblaries simply shows how immature IT industry is
today.

Michal

Mime
View raw message