(bringing over to maven dev as Steve suggested) On 5/19/05, Steve Loughran <[EMAIL PROTECTED]> wrote: > 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.
Right - this is the direction we are pushing. To get dependencies to specify the versions they recommend, but because we still have "nearest wins", you always get to veto that if necessary. > 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. http://docs.codehaus.org/display/MAVEN/specification+dependencies In my mind it was bettter to leave this for a later Maven 2.1 feature release, after we were confident with the versioning aspects of normal dependencies, because this adds an extra level of complexity on top of that. And a lot of specifications have found their way into the JDK so become specified explicitly less. > > 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). Absolutely. I was just suggesting an algorithm that would determine the best version unaided, but when it comes down to it the final project has to decide. In a lot of cases, an older version might work just fine because several other projects have overstated their needs, but a warning is still a good idea. > 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. yeah, I think they are separate. the rest sound like the conflict strategies I'd envisage. There may be others as well (eg, deploying to a particular appserver, so make sure you get version X of all these because they'll be forced on you). I'm not sure "no transitiveness" is a good idea. I think it's something that once available, people will use as the quick fix to a problem rather than figuring out a real cause, and miss an opportunity to improve the overall quality of the data. Which would be ironic, given how long people asked for transitive deps - to turn it off so quickly - but I knew that it would come because as you said earlier, version management isn't a trivial problem. If you are the one building the libraries, it requires discipline to keep compatibility, consistent naming, etc. I'd prefer to be able to filter out unwanted dependencies as an alternative to turning it off. > I've just subscribed to maven dev; I will discuss it there. welcome :) I've been planning to take a pass at this design for alpha-3 tomorrow, so I'll reply to anything else in the morning. Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
