Any idea how to determine all the JAR dependencies a give JAR has?
"Mike Hogan" <[email protected]> Sun, 14 Dec 2003 20:32:15 +0200
| Newsgroups | gmane.comp.java.jcontainer.interest |
|---|---|
| Message-ID | <000701c3c270$994641f0$3a83ba50@eamon> |
Hi all, I have completed the first iteration of dependency support in componenthaus. When a component is submitted, its compile time classpath is snapshotted, and all the jarfiles in that classpath are resolved against www.ibiblio.org, dist.componenthaus.org and the local componenthaus repo, and when you perform a download, you get one big zip file containing everything you need. Well, not quite. Snapshotting the compile time classpath gets only the first level of dependencies. JARs in the compile time classpath will surely have dependencies themselves. Lets say I am submitting a jar file called MikesComponent.jar. It has a compile time dependency on spice-threadpool-0.1.jar. We can handle that, as it'll be in the compile time classpath. But spice-threadpool has dependencies on things like avalon. How can I get that information? For the sake of discussion, I will outline what I have been thinking: * A maven repo should have a small XML file detailing the runtime dependencies for each jar in the repo. When I see that spice-threadpool-0.1.jar is a dependency on MikesComponent.jar, I can parse that XML file and determine what else is required, and so on recursively. This XML file need be no more than the <dependencies> section of the Maven POM. * Dependencies can be maintained in componenthaus by hand. So administrators/component submitters can punch in data saying that spice-threadpool-0.1.jar depends on avalon-2.3.jar etc. No way of ensuring data quality here though, unless there is a feedback feature. * Other less pleasant ideas, like requiring each componenthaus submission to have the necessary metadata, and writing a static analysis tool that finds all dependencies and compares their names against whats available in all the maven repos out there. What do you think? How should we approach this? Cheers, Mike. PS One additional consideration is that compile time dependencies can be different to runtime dependencies.