(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
got it. yes, JAXP is the case in point. you dont care what people built against, as long as it is the same version of the spec. Maybe projects need to declare they were built against an API for xml, just like commons-logging-api.
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.
yes, it is just that I cant currently import Xom, for example, because it pulls in jaxen which pulls in dom4j. I now have a private release with a dependency-free POM in my local cache.
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).
aah, and then there are endorsed directories, worst case of all 'we know better' overrides.
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.
yes, a block would work.
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.
ok. one more troublespot is that no pom should be a warning, not an error. there are things on the site without poms, and it is easier to pull third party libs in to shape without writing pom files. That said, it'd be nice to have a set of .pom files to go with the various java libraries, maybe even some client program to do the retrieve/clickthrough/version-tag/save processing to bring them into the repository structure.
-steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
