On 5/17/05, Dominique Devienne <[EMAIL PROTECTED]> 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 another.
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 conflictthough 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, http://jira.codehaus.org/browse/MNG-303
I've just subscribed to maven dev; I will discuss it there.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
