这更多的是一个关于现有内容的问题，以及关于解决Ivy等工具的未来方向。有没有什么东西可以提到包的class-level依赖性，而不是package level依赖性
例如，假设我有一个apache-xyxy package，它附带了一个列出所有依赖项的ivy.xml。但假设我只在apachexyxy中使用WX类，它不需要这些依赖项中的大部分。难道解析器不能是智能并确定类WX只能调用其他类（AB、DC、EF）的集合，并且这些类都不使用任何其他依赖项，以创建所需依赖项的最小子集吗？这将比精心挑选删除一些由于包中使用的特定类而不需要的包依赖项更容易、更安全，还可以防止仅仅因为这个原因将几个较大的包分解为较小的包。
然后，如果我后来决定使用apachexyxy中的GH类，我可以进行ivy解析，它将动态地引入额外的所需库。
在打包编译的java代码进行分发时，通常将java"包"捆绑在一起。将一个java包拆分到多个jar中也是很可能的（但很愚蠢）。大型框架（如Spring）在不同的jar中有很多子包，这样用户就可以在运行时选择他们需要的东西。。。。。当然，jar选项越多，填充运行时类路径就越复杂。。。
这里的关键词是"运行时"。。。。像ApacheIvy和ApacheMaven这样的工具主要是为了管理构建时所需的依赖关系而设计的。。。。
ApacheMaven确实有一个"运行时"范围，因为它有依赖关系，但它仅限于一个jar列表。通常，这个范围用于决定测试和填充WAR文件的lib目录需要哪些jar。
Apache ivy有一个类似的更灵活的机制，称为"配置"。可以根据需要创建任意多的运行时配置，这些配置可以用来决定ivy下载了哪些jar。因此，虽然ivy似乎有答案，但我很少看到在启动程序时使用ivy（一个例外是Groovy的Grape注释）
那么，你可能会问，答案是什么？
"运行时"类路径管理的未来要么是OSGI，要么是项目拼图。我更熟悉OSGI，其中在jar文件的清单中添加了特殊的依赖项指示符，说明它的依赖项是什么。这个想法是，当容器加载一个jar（称为"bundle"）时，它可以检查并查看其他依赖项是否已经加载。这些依赖关系可以从公共存储库中检索和加载。这是启动java的根本不同的方式。传统上，每个应用程序都加载到自己的独立类路径上。。。。。
时间会告诉我们这两个项目是否成功。同时，我们使用Apacheivy和ApacheMaven来构建自包含的、可能过于臃肿的WAR（EAR等）包。