ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: <libraries> and m2 <artifact :>
Date Thu, 19 May 2005 10:42:18 GMT
Brett Porter wrote:
> On 5/17/05, Dominique Devienne <> wrote:
>>I've used a more lenient model for my transitive dependency. The exact
>>version used to build something is recorded, but which version of a
>>given dependency to use is left up to the client. 
> This is pretty much what is in Maven (and the artifact tasks) at the
> moment. It uses the "nearest" definition for conflict resolution. So
> declaring in the POM of the current project can ensure a particular
> version, otherwise you'll get one at depth 1, etc.
>>A colleage proposed an interesting idea of using predicates to state
>>compatibility between components the different version of a component.

One thing we all have to remember is that versioning is something 
neither the CS or software engineering community have solved. Upgrades 
can cause problems. But on the plus side, given the absence of strict CS 
notions of compatibility, we can build things that only work sometimes 
and get away with it :)

1. there is no way to guarantee consistent behaviour across versions. 
Languages with more declarative pre- and post- conditions can do more 
internal validation; java could use asserts more if Java1.4 was the minimum.

2. it is not enough to have the right set of components, the system 
configuration must match what is required.

3. in a distributed system, it is the state of the entire network that 
defines the effective behaviour of a remote component.

4. what can you do then? Test, that is all.

A key issue w/ transitive dependencies is that I may not want a library, 
just because it was used in a library I want. Certainly I need the right 
to override versions. This is why dependency declarations in JAR file 
manifests is so broken; the builder of the jar is telling the deployer 
what files they MUST use, not what files they SHOULD use.

One thing I've felt might be good in dependency declarations (or in the 
POM) would be for something to declare what well-known-APIs they 
implement. So that if one version of JAX-RPC is declared, you don't need 

> What we have is pretty basic, and we're definitely looking to improve
> it with some other types of resolution, such as what you've described.
> Ideally, a project would declare the minimum version it needs to work
> (and if applicable, maximum - or perhaps even known incompatible
> versions in between). The final project should use the most recent
> version allowed by all of the definitions (on the assumption that the
> most recent is backwards compatible and has less bugs than earlier
> versions :)

That's one assumption, but I take the view is that If I explicitly ask 
for an older version, I should get that (albeit maybe with a warning). 
Maybe the version policy could be pluggable

policy=none   //no transitiveness
	newest-wins  //newest matters
	nearest-wins //closest declaration matters
	fail //fail on conflict

though I think I'm mixing policy of transitive on/off with conflict 
resolution here. hmm.

> Again, local definition of an explicit version will ensure you get
> what you ask for.
> This also has important consequences for making builds reproducible in
> the future, too - obviously if the version remains flexible at the
> point it is published then it might not be the same later on. There
> needs to be a point during QA where you can lock it down to a version.
> if you'd like to track the feature,

I've just subscribed to maven dev; I will discuss it there.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message