Ric*_*ler 47
没有构建系统是一个神奇的子弹.我发现Maven解决的问题多于它对我的影响,但我很乐意编写插件来解决它的缺点,我也处理了数百个项目,所以Maven的继承和依赖处理对我很有帮助.
浏览SO一点,你会看到Buildr和摇篮双方也有问题(相同的蚂蚁和常春藤),通常你的交易一组问题,另一个和它找到最痛苦的情况.
是否有任何特别困扰你的Maven或者它是一般的痒？如果是很值得期待的一个具体问题上吉拉Maven的3个问题,如果这个问题不解决,就可以提高它,否则有可能会小点,在你等待
Ste*_*ver 47
Maven 3的Maven谱系背后的人们总是认为项目构建是同质的,即:所有构建问题从根本上归结为同样的问题.面对相反的观点,这种世界观可以相当一致,但需要付出代价.Maven中缺少脚本逻辑("当你想要脚本时,你知道你做错了什么"),繁琐的插件API("没有普通的Maven用户应该想要编写插件")和中央存储库("我们都具有相同的依赖性")是这个总体假设的所有证明.
在现实世界中,构建问题是异构的,因为人们出于各种各样的原因构建软件.他们都像我们所有'钻孔'一样"发展",偶尔解决独特的问题.无论您的抽象级别如何,在比较任意构建问题时,您总会发现相似之处.这些相似之处和对差异的谴责是Maven设计的垮台以及它为什么会引起如此大的抨击的原因.基本上,Maven的前景是专制和乌托邦.
PS:Maven具有很好的功能,例如配置约定和使用存储库的想法(Maven实现这个想法很麻烦).
Dav*_* W. 18
我们在这里使用Maven,但是我发现一旦你超出了一个简单的项目,pom.xml开始变得越来越复杂.你开始花费大量时间来解决如何配置你的pom来做你想做的事情,以及如何解决各种问题.
真正让我感动的是我们正在建造的耳朵.我们在那个ear文件中有多个战争,而Maven通常会将这些库包含在战争中.但是,为了减少战争的规模,并使罐子保持不变,我们希望将战争之间的罐子放在耳朵的lib目录中.
不幸的是,Maven并没有很好地处理这个问题.我们需要为每个战争的poms手动配置它,然后将所有这些依赖项添加到耳朵的pom中.
在另一个项目中,我们有基于HTML的帮助文件.编写帮助的人在Microsoft Word中编写它们然后使用程序将它们转换为HTML.单个字符更改可以在数百个文件中产生混响.
为了解决这个问题,我们的帮助系统作为单个压缩文件存储在我们的源存储库中.当我们的文档团队创建一组新的帮助文件时,他们会将其压缩并替换存储库中的文件.
因此,我的部分构建解压缩此文件并将其置于战争中.在Ant中很容易做到,除非你使用Antrun插件允许你编写Ant代码来处理Maven在没有完整插件的情况下无法处理的问题,否则不能在Maven中执行.
我可以看到Maven在做什么,但理论领先于现实.我发现Ivy和Ant可以完成Maven所做的大部分依赖性检查,而没有编写和维护poms的所有问题.
如果您还没有使用Maven,请首先尝试使用Ivy Ant.然后,当Maven 3出来的时候,尝试一下.我记得从Maven 1到Maven 2的过渡.它们彼此完全不兼容,你使用Maven 1学到的任何东西都已经过时了.在Maven 2中学习和重做你的项目是很愚蠢的,突然发现自己为Maven 3重做了一切.
小智 5
Maven 2和3在各种项目中都非常适合我.我目前正在使用Maven 3 alpha 7,它运行得非常好,特别是与Eclipse Maven插件结合使用.
Maven在两个方向上与Ant无缝集成.在我当前的项目中,我们多次从Ant调用Maven以执行复杂的集成测试.同样,我们使用Ant通过Maven的AntRun插件,我们也编写了自己的Maven插件.顺便说一下,这只需几分钟就可以归结为写一个带注释的Pojo.
Maven因为许多开发人员不喜欢规则或惯例而受到很多抨击.很简单,没有人强迫你使用Maven.如果您想要最终的自由 - 无论如何 - 为您加入的每个项目重新编写自己的构建过程.但是,如果您想创建软件而不是在每个项目上使用定制的构建过程重新发明轮子,请选择Maven.
| 归档时间： |
|
| 查看次数： |
28811 次 |
| 最近记录： |