平台强制版本控制机制是java最急需的功能吗？

Question

作为开发人员,我经常对可以让您的生活更轻松的新语言功能感兴趣.例如,java 5为该语言带来了泛型和注释,这些功能绝对可以提高您的工作效率.

然而,当我回顾近十年来在java平台上工作时,我发现与版本相关的问题是非生产性和不必要的努力的最大罪魁祸首.寻找正确版本的jar的小时和小时,试图协调一些版本冲突,升级依赖库等.当我开始使用java时,事情并不那么困难,你有几个第三方库,就是这样.今天,您可以轻松使用典型的Web应用程序:Spring Framework,Hibernate,Struts,您可以使用它.所有这些都带有许多依赖的第三方库.今天,我的耳档将通常包括大约40个或更多第三方库.一个真正的罐子地狱!

使用注释,我不必管理Hibernate的配置文件.一个很好的功能,但我没有看到由于我将描述符保存在单独的文件中而引起的许多问题.使用泛型,我不会编写演员语句,但在我的整个编程载体中,我记不起一个可以通过使用类型安全容器来防止的错误.版本问题的解决方案不是更有价值吗？

所有这些问题导致了许多工具,如Maven,Ivy,One Jar,Jar Jar Links(不是开玩笑!),甚至恰当地命名为Jar Hell等.即使你使用其中一些工具,你也远远不能免疫问题.我使用Maven 2,这是一个很好的帮助.不过,它本身就是一个世界.新手程序员可能需要一段时间来学习它.将您的遗留项目迁移到Maven结构也很痛苦.

似乎在.Net中他们已经学会了dll地狱的教训,并且.Net程序集的管理要简单得多.

似乎有计划为java平台和OSGI等替代方案解决这个问题.我认为非常需要一些基本的和平台强制的版本控制机制

Answer 1

我已经使用Java十多年了,但我不得不说我根本没有发现很多JAR地狱问题(甚至使用你提到的所有第三方工具)!我发现Maven这是一个可怕的工具,所以建立一切ant.

在我们公司,我们有一个ant基于每个项目的简单(小)依赖文件的定制依赖解决任务,同时将每个项目定义为一个app或一个lib(你应该只依赖于a lib;永远不会app).它工作得很好.

我们还有ant修改eclipse .classpath和IDEA .iml文件的任务,以便为我们的IDE生成依赖图.

Answer 2

看看 OSGi - 它很好地处理了包（jar）的版本控制和管理。

另外：Eclipse（构建在 OSGi 之上）有一些相对较新的 API 工具，可以帮助您将 API 与之前的基线进行比较，并确定如何正确表达捆绑包的下一个版本号。

一般的 Eclipse 版本控制方案：

v.m.n.q

在哪里

v：高级版本 - 此处的更改通常代表 API 中的重大更改

m：主要变化 - 新功能、新 API

n：细微变化 - 相同的 API，幕后变化

q：限定符 - 用于标记构建、alpha/beta 等

OSGi 使用范围指定版本依赖性。例如

Require-Bundle: com.javadude.foo;bundle-version="[1.2.0,2.0.0)"

在 MANIFEST.MF 中指定该捆绑包需要 com.javadude.foo 版本 1.2.0 或更高版本，直至（但不包括）版本 2.0.0。

您还可以在包级别指定依赖项。