On 5/16/05, Steve Loughran <[EMAIL PROTECTED]> wrote: > I think what is happening is that the maven dependency model does work > if you live only in maven-land (that is, provide your own poms, only set > up classpaths via the dependency declarations). In this world, > dependency logic should be a lot better than the classic > whatever-is-in-the-filesys classpath setup we know and use. But trying > to merge the two hurts. > > There is some mention in the docs of a "scope" switch, which seems to > control some of this, but doesn't have a "no-transitive-fetching" > option, which is what we need. Without that, it is unusable in ant > itself, which does not bode well for other projects. Indeed, I cant seem > to use it any of the three I've tried as eventually this transitiveness > hits a brick wall somewhere in the dependency chain of the various XML > tools.
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. By default, we assume backward compatibility and take the latest of the dependency, but it can be customized by dependency by the client itself. (we actually break up the version in two: a CVS branch tag, and a build number. We usually say use the latest build of a given branch). How does Maven resolve conflicting dependency? A depends on B and C, both depending on D, but B depends on D v1, when C depends on D v2? A colleage proposed an interesting idea of using predicates to state compatibility between components the different version of a component. The predicates are embedded in the 'POM' of a released component. So D v2 states being BC with D v1, and thus when getting the dependencies for A, you get D v2. I need to implement his idea eventually. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
