We implemented that functionality with a wrapper around a static analysis tool called JarJar: http://code.google.com/p/jarjar/
This tool will give a list of dependencies on a jar to jar level for a given classpath. We parse the output and use it to generate an ivy.xml with the compile time dependencies. If you are interested I can send you our BeanShell wrapper - it is not worth posting as it is not very generic, since it has to deal with our own organization and module naming conventions. Developers were expected to do a second pass fixing organizations and module names and adding runtime dependencies. I think you might be able to generate test and runtime "correct" dependencies as well using a profiler or aspects - assuming you trust your test coverage to be good enough. Good luck, Nascif ________________________________________ From: Maarten Coene [EMAIL PROTECTED] Sent: Wednesday, October 08, 2008 3:37 PM To: [email protected] Subject: Re: Reinforce dependency control There is a very basic (and undocumented) task in Ivy that generates an ivy.xml from the import statements found in your sources. Just take a look at the IvyExtractFromSources task. Not exactly what you were looking for though Maarten ----- Original Message ---- From: Gilles Scokart <[EMAIL PROTECTED]> To: [email protected]; Ant Users List <[EMAIL PROTECTED]> Sent: Wednesday, October 8, 2008 3:40:30 PM Subject: Reinforce dependency control When working on some big project with heavy history and when looking at the quality of some meta data in the maven repository I'm always shoked by the amount of useless dependencies used. To counter that, I would like to use (and promote) a tool that help the developpers to limit their path to the strict minimum. I would like to start with the easiest : the compile path. (Next I would try to do the same for test classpath, and maybe for runtime classpath) I would like to push my build to an extreme solution. I want to make a build fail if some jars of the compile path are not used. Did you know a task that do that? Or did you know any tools that list the jars that are required by a sources (or a compiled jars) that I could adapt to make such a tasks? -- Gilles Scokart
