This is more a question about what’s out there, and future directions about resolving tools such as Ivy. Is there anything that can mention class-level dependencies for packages, rather than package level dependencies?
For example, let’s say I have an apache-xyxy package, that comes with an ivy.xml that lists all it’s dependencies. But suppose I only use class WX in apache-xyxy, which doesn’t require most of those dependencies. Couldn’t a resolver be intelligent and identify that class WX can only possibly invoke the set of other classes (AB, DC, EF), and none of those classes use any of other dependencies, to create a minimal subset of required dependencies? This would be easier and safer than cherry picking to remove some package dependencies that aren’t needed because of the specific classes used in that package, and also prevent breaking down several larger packages into smaller ones just for this reason.
Then, if I later decided to use class GH from apache-xyxy, I could do an ivy resolve, and it would dynamically bring in the additional required libraries.
When packaging compiled java code for distribution it’s common practice to bundle Java “packages” together. It’s also quite possible (but silly) to split a java package across multiple jars. Large frameworks (like Spring) have lots of sub packages in different jars so that users can pick and choose what they need at run-time….. Of course the more jar options one has, the more complex it becomes to populate the run-time classpath…
The keyword here is “run-time”…. Tools like Apache ivy and Apache Maven are primarily designed to manage dependencies needed at build time….
Apache Maven does have a “runtime” scope, for it’s dependencies, but it’s limited to a single list of jars. Typically this scope is used for deciding which jars are needed for testing and populating the lib directory of a WAR file.
Apache ivy has a similar more flexible mechanism called “configurations”. It’s possible to create as many runtime configurations as you need, and these can be used to decide which jars are downloaded by ivy.
So while it would appear ivy has the answer, I’ve rarely seen ivy used when launching programs (The one exception is Groovy’s Grape annotations)
So what, you might ask, is the answer?
The future of “run-time” classpath management is either OSGI or project jigsaw. I’m more familiar with OSGI where special dependency indicators are added the the jar file’s manifest, stating what it’s dependencies are. The idea is that when a container loads a jar (called a “bundle”) it can check and see whether the other dependencies are already loaded. These dependencies can be retrieved and loaded from a common repository. This is fundentally different way to launch java. Traditionally each application is loaded onto it’s own isolated classpath…..
Time will tell if either project catches on. In the meantime we use Apache ivy and Apache Maven to build self-contained and possibly over-bloated WAR (EAR, etc) packages.