我有一堆由同一团队拥有的顶级软件包。所有顶级套餐都使用弹簧。然后有一些库（jar）是顶级包之间的共享功能和实用程序。所有非常标准的东西。
在某些情况下，在库包中使用spring是有意义的。假设我有一系列共享的方面，我想使用spring的@ Aspect / @ Before / @ After等注释。
问题在于，有相当大的顶级软件包使用spring 2.5.6依赖项编写，而较新的顶级软件包是在spring 3中创建的。我通常认为这是一件好事。
但是现在有一个小问题，我现在有了依赖于spring-2.5.6的库，而那些不能被spring-3顶级软件包使用，因为版本不匹配（我正在制作在这里假设吮吸两个不同的弹簧版本是一个非常糟糕的主意）。似乎我的选择是避免库中的spring依赖，或者接受我的库需要提供多个版本（对于顶级包级别使用的每个spring版本为1）。选项1似乎比选项2更可取，但我希望有一些有趣的技巧可以让我获得两全其美的效果。
如果有一些Java标准（@Inject？）那么我可以依赖javax的东西，而不是春天特定的东西。不幸的是@Inject等仅支持Spring 3+以便在未来的某个时间点解决我的问题，但只要我有2.5.6应用程序它就没有帮助。
想法？
我应该注意到有一些现有的库依赖于spring-2.5.6而且我认为这是将顶级软件包升级到spring-3的一种威慑。因为升级顶层包也意味着版本碰撞依赖于spring的N库，这很烦人，因为我甚至不知道这些库的完整消费者集，以及他们可能会想到弹簧版本突然被碰撞
编辑：
我想知道我是否可以创建一些库，并在提供的范围内创建一个spring依赖项。弹簧版本是我可以选择的最小版本，以获得我想要的功能集，所以理想情况下我会使用2.5.6使其与spring 2.5.6应用程序和spring-3.0.5应用程序兼容。然后，当消费应用程序创建对我的库的依赖时，它还将为该应用程序生效的真实spring版本创建spring依赖项。我认为这应该有用，只要spring版本是＆gt; =我为我的库选择的版本（我碰巧知道2.5.6是所有应用程序使用的最低版本）。
我的另一个选择是根本不创建spring依赖项，而是提供一个可以在调用应用程序中导入的spring.xml。这意味着我不能使用注释或像InitializingBean这样的东西，但一般来说spring提供了一种通过注释或xml或两者来做事的方法，所以这应该也可以。
思想？
答案 0 :(得分：2)
正如您正确提到的，同时拥有2.5.6和3.0 Spring依赖项会产生问题。在运行时只会选择一个版本，这意味着您的顶级打包模块将失败或其他共享实用程序将失败（取决于Spring的版本）。
在Java Classloader - how to reference different versions of a jar中讨论了类似的问题。它与Spring没有直接关系，但我想不出直接解决你的问题。 OSGi是一种可能的解决方案，但不确定它在您的环境中的可行性，因为它需要更改容器本身。
答案 1 :(得分：0)
a）@Aspect @Before @After：这些注释都在aspectjrt.jar中，而不是Spring本身。他们应该使用任何一个版本
b）@Inject无效，@Autowired将无效。