我想弄清楚什么是处理应用程序服务器中依赖关系的最佳方法。我们正在考虑构建应用程序的maven,但我们发现了一个问题。它出现时,我们需要更新没有版本number.This专有共享库每月发生一次,我们使用的是WebSphere共享下列方式库函数:在Java中管理部署依赖关系
- 在WebSphere我们每个共享库创建一个没有版本的别名。例如:db-component-1.2.1接收别名db-component。在第一次部署期间,我们使用别名将应用程序与所需的库相关联。由于我们忽略版本,所有应用程序必须使用相同的版本,从而创建一些限制。但是,当我们需要升级共享库时,我们只需在WS中上传新库,然后所有应用程序都使用更新版本。
我们有超过70个依赖专有共享库的应用程序。这些库不断变化,这种解决方案使管理变得更加简单。但是,在应用程序的构建过程之外,依赖关系发生了变化似乎有点奇怪。依赖控件不再可靠,因为应用程序的POM中的信息可能是错误的。另外,所有应用程序必须使用相同的版本。
我认为可能存在更好的解决方案。
我们考虑过另一种模型。在每场战争中都包含依赖关系。这允许我们在每个应用程序中使用不同版本的库,而不受任何限制。但是有一个问题:当在专有共享库中进行更改时,我们需要重新构建并重新部署所有应用程序。
我曾考虑过我们的专有共享库如此不稳定或者使用了一种混合了这两种想法的解决方案,但我不知道如何解决这个问题。 OSGI看起来像是一种更好的方式来处理依赖关系,但我们在升级很多应用程序时会遇到同样的问题。
我们应该使用WS的共享库函数吗?有没有更好的方法来解决这个问题?提示非常感谢。
感谢
我确实在寻找关于“它更好地具有显式依赖还是一些共享依赖集”的建议。你的建议给了我一些想法。我会检查这个插件。 可重复构建非常重要,但它会产生部署60个应用程序的操作问题。你有类似的情况吗?这是你如何处理它? – 2010-08-24 20:33:39
我们一直使用maven/nexus/version插件组合来显式版本化所有的依赖关系,当我们更新共享代码时,我们从不需要担心检查所有单个项目的突破性更改。任何需要特定非当前版本的问题都很容易识别(仅在〜6个月内发生过一次) – 2010-08-24 21:11:54