Hi Stephen I agree; each jar you're dependent on should be able to have its own dependencies. e.g. using commons-digester means you have to use commons-logging, commons-beanutils and commons-collections. So it'd be nice to not have to manually flatten the dependency trees, or only flatten/mention those jars that you have specific requirements on. Increasingly we could expand this idea to do version checks, testing for incompatible combinations of products and such like.
Though options A and B that I mentioned I could really do with now, I'm happy to wait for the jar dependency feature ;-) James ----- Original Message ----- From: "Stephen Haberman" <[EMAIL PROTECTED]> To: "'Turbine Maven Developers List'" <[EMAIL PROTECTED]> Sent: Thursday, May 23, 2002 8:57 PM Subject: RE: extending the notion of dependencies... > Along the same lines, I've been putting together a project that uses > Turbine and the amount of dependencies Turbine requires is quite large. > I was thinking that instead of having to include any Turbine-related > dependency, plus all the dependencies of Turbine's dependencies, and on > down the line explicitly in the project.xml file, what if Maven could > automatically track dependencies? > > My idea is a lot like James's option B, which is certainly very cool, > but I'd like to see it work for any jar you'd want to use, not just > Maven-enabled projects. > > Perhaps not automatically; the HTTP repository could have something like > a dependencies.xml that would look like: > > <dependencies> > ... > <jar name="turbine-xxx.jar"> > <dependency>stratum-xxx.jar</dependency> > ... > <dependency>velocitry-xxx.jar</dependency> > </jar> > .. > </dependencies> > > So that whenever turbine-xxx.jar (or any other jar in the repository) > was listed as a root dependency of a project, Maven could find out it > also needed to include the stratum and velocity jars. > > And perhaps automatically; e.g. whenever a ClassNotFoundException > occurs, Maven could skim the missing class from the compiler's error > output and scan the lib.repo and HTTP repository for the missing class. > > I don't know about the validity of skimming idea; it just came to me. > But it'd be cool in that then no one would have to worry about > maintaining a dependencies.xml-type file. > > Any files Maven subsequently finds in the dependency list could then be > mapped out in the documentation as a dependency tree. > > I can't be as generous as James and offer to submit patches for these as > I haven't looked at the code base for Maven yet. Though it sounds > intriguing and I could take a stab at implementing it if the group likes > the idea and it ferments a little bit. > > - Stephen > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
