T******7
发帖数: 1419 | |
d****i
发帖数: 4809 | 2 Maven is much much more popular than Ant. Almost almost Java code
repositories use Maven. Maven build system for Java is equivalent to
Makefile for C/C++ in Unix/Linux.
【在 T******7 的大作中提到】
: 谁能比较一下ant和maven的有点缺点？
|
T******7
发帖数: 1419 | 3 我们还用ant 不知道为啥tech lead选ant |
l**********n
发帖数: 8443 | 4 How ant handle dependencies?
【在 T******7 的大作中提到】
: 我们还用ant 不知道为啥tech lead选ant
|
r**i
发帖数: 1222 | 5 ivy
【在 l**********n 的大作中提到】
: How ant handle dependencies?
|
w***g
发帖数: 5958 | 6 ant = rpm = dpkg = Makefile
maven = yum = apt-get = ??? 这个对应的东西C++世界还没有。
【在 d****i 的大作中提到】
: Maven is much much more popular than Ant. Almost almost Java code
: repositories use Maven. Maven build system for Java is equivalent to
: Makefile for C/C++ in Unix/Linux.
|
d****i
发帖数: 4809 | 7 这个难道不是make install吗？C/C++ source code build and install
make all
make install
【在 w***g 的大作中提到】
: ant = rpm = dpkg = Makefile
: maven = yum = apt-get = ??? 这个对应的东西C++世界还没有。
|
w**z
发帖数: 8232 | 8 现在流行 gradle
【在 T******7 的大作中提到】
: 谁能比较一下ant和maven的有点缺点？
|
g*****g
发帖数: 34805 | 9 ant就像makefile，很直接的脚本，这东西的出现在这个世纪初，那时候开源类库不多
，主要是self-contained的utility类库。后来spring, hibernate出现，开源类库井喷
，Spring自己就是N个类库，N个版本，一堆类库又用它，结果conflict极多，手工处理
很繁琐。Maven这样的dependency management system极大地解决了这个问题。Maven作
为个Repository是划时代的，但其Client脚本功能很弱，你想拷贝个文件都得弄个
plugin，很繁琐。于是就有了ivy，这个东西算是把ant和maven的优点结合起来，但性
能不佳，xml也很繁琐。这时候Groovy已经有了，于是出现了Gradle，同样可以使用
maven repository，但同时可以直接写Groovy代码，愿意的话可以去打开个数据库读个
field来决定版本啥的。就是个简洁加强版的ivy。现在趋势所有的新项目都在向gradle
转。
【在 T******7 的大作中提到】
: 谁能比较一下ant和maven的有点缺点？
|
T*******x
发帖数: 8565 | 10 maven解決conflict是靠maven central repository 网站解决的吧？
gradle
【在 g*****g 的大作中提到】
: ant就像makefile，很直接的脚本，这东西的出现在这个世纪初，那时候开源类库不多
: ，主要是self-contained的utility类库。后来spring, hibernate出现，开源类库井喷
: ，Spring自己就是N个类库，N个版本，一堆类库又用它，结果conflict极多，手工处理
: 很繁琐。Maven这样的dependency management system极大地解决了这个问题。Maven作
: 为个Repository是划时代的，但其Client脚本功能很弱，你想拷贝个文件都得弄个
: plugin，很繁琐。于是就有了ivy，这个东西算是把ant和maven的优点结合起来，但性
: 能不佳，xml也很繁琐。这时候Groovy已经有了，于是出现了Gradle，同样可以使用
: maven repository，但同时可以直接写Groovy代码，愿意的话可以去打开个数据库读个
: field来决定版本啥的。就是个简洁加强版的ivy。现在趋势所有的新项目都在向gradle
: 转。
|
|
|
w**z
发帖数: 8232 | 11 pom.xml 每个dependency 都指定需要的版本。
【在 T*******x 的大作中提到】
: maven解決conflict是靠maven central repository 网站解决的吧？
:
: gradle
|
T*******x
发帖数: 8565 | 12 可是经常pom.xml只有很少几个dependency, 执行的时候却下载了一大堆东西。很多是
自动解决版本号的吧？是central repository网站解决的？
【在 w**z 的大作中提到】
: pom.xml 每个dependency 都指定需要的版本。
|
w**z
发帖数: 8232 | 13 每个 dependency 自己也有 dependency, 叫 transitive dependencies。
repository 可以在pom 里设定，不设的话，会去default 的。一般建议在 settings.
xml 里设。
【在 T*******x 的大作中提到】
: 可是经常pom.xml只有很少几个dependency, 执行的时候却下载了一大堆东西。很多是
: 自动解决版本号的吧？是central repository网站解决的？
|
g*****g
发帖数: 34805 | 14 This is like DI, a bean only declares what it depends on, but those bean can
have their own dependency. It's a graph and issues can arise when there are
conflicting versions or there are cyclic dependencies.
【在 T*******x 的大作中提到】
: 可是经常pom.xml只有很少几个dependency, 执行的时候却下载了一大堆东西。很多是
: 自动解决版本号的吧？是central repository网站解决的？
|
w**z
发帖数: 8232 | 15 that is the pain for all the big projects. In Maven, you can try to use "
exclude" on the transitive dependencies to alleviate the pain a little bit.
Is there a good way to solve it? I have seem some pom.xml which is more than
300 hundred lines. It's hard to maintain.
can
are
【在 g*****g 的大作中提到】
: This is like DI, a bean only declares what it depends on, but those bean can
: have their own dependency. It's a graph and issues can arise when there are
: conflicting versions or there are cyclic dependencies.
|
g*****g
发帖数: 34805 | 16 Unfortunately no, ideally every lib author should keep dependencies lean, as
lean as possible. But it's often an afterthought effort. So you end up
doing excluding and overriding. My average gradle file is 100 lines, that's
like 300 lines translated to pom. I think the only thing that helps is SOA
and keep your project from growing too big. Also CI tools can help your
identify what change makes the break before you are stuck too deep.
.
than
【在 w**z 的大作中提到】
: that is the pain for all the big projects. In Maven, you can try to use "
: exclude" on the transitive dependencies to alleviate the pain a little bit.
: Is there a good way to solve it? I have seem some pom.xml which is more than
: 300 hundred lines. It's hard to maintain.
:
: can
: are
|
T*******x
发帖数: 8565 | 17 举个例子吧。比如我的pom.xml里面有这么一个dependency：
org.springframework
spring-context
3.1.1.RELEASE
用eclipse看dependency hierarchy，发现它depend on
spring-aop
spring-beans
spring-core
spring-expression
spring-asm
这些都不在我的pom.xml里面。那么这些dependency information
是在哪里存贮的？是在maven central repository网站存储维护的吗？
【在 w**z 的大作中提到】
: 每个 dependency 自己也有 dependency, 叫 transitive dependencies。
: repository 可以在pom 里设定，不设的话，会去default 的。一般建议在 settings.
: xml 里设。
|
g*****g
发帖数: 34805 | 18 对，每个类库都有一个 POM文件，找不到就出错。
【在 T*******x 的大作中提到】
: 举个例子吧。比如我的pom.xml里面有这么一个dependency：
:
: org.springframework
: spring-context
: 3.1.1.RELEASE
:
: 用eclipse看dependency hierarchy，发现它depend on
: spring-aop
: spring-beans
: spring-core
|
w**z
发帖数: 8232 | 19 pom.xml 指定dependency， 至于从哪里下载这些dependency artifact， settings.
xml defines the repository location. You can also define it in pom.xml which
is less desirable IMO
【在 g*****g 的大作中提到】
: 对，每个类库都有一个 POM文件，找不到就出错。
|
T*******x
发帖数: 8565 | 20 谢谢。
我在maven local repository (.m2)里找到了spring-context所在的目录，
里面主要有两个文件，一个是spring-context.jar，另一个是spring-context.pom。
jar里面没有dependency信息，这些信息是在pom文件里。
也就是说，maven central repository网站，
对每一个jar文件都整理了一个pom文件，其中存贮它的dependency。
所以maven解决类库conflict最终是靠central repository网站维护。
对吧？
maven我一直没搞明白，觉得很confuse。
比如这个spring-context类库，我如果不用eclipse工具看的话，
根本不知道它depend on spring-beans类库。
在这种情况下我会把两个都写在我的pom.xml里。
比如这样(请注意这两个版本不一样）：
spring-context
3.1.1
spring-beans
3.2.2
那这样不又产生版本冲突了吗？
另外这个artifactId和version都需要自己记下来，或者有一个模板copy paste，
否则很容易写错啊。
【在 g*****g 的大作中提到】
: 对，每个类库都有一个 POM文件，找不到就出错。
|
|
|
T*******x
发帖数: 8565 | 21 settings.xml在哪个目录里？
which
【在 w**z 的大作中提到】
: pom.xml 指定dependency， 至于从哪里下载这些dependency artifact， settings.
: xml defines the repository location. You can also define it in pom.xml which
: is less desirable IMO
|
g*****g
发帖数: 34805 | 22 你看到的这些文件是从远端repository当下来的。conflict是在 client端解决的，不
是server端，server只是个repository.
解决conflict缺省就是最简单的用靠后的版本，但你可以对每个dependency override
和exclude。你应该找个tutorial读一下，光问问题是问不明白的。
【在 T*******x 的大作中提到】
: 谢谢。
: 我在maven local repository (.m2)里找到了spring-context所在的目录，
: 里面主要有两个文件，一个是spring-context.jar，另一个是spring-context.pom。
: jar里面没有dependency信息，这些信息是在pom文件里。
: 也就是说，maven central repository网站，
: 对每一个jar文件都整理了一个pom文件，其中存贮它的dependency。
: 所以maven解决类库conflict最终是靠central repository网站维护。
: 对吧？
: maven我一直没搞明白，觉得很confuse。
: 比如这个spring-context类库，我如果不用eclipse工具看的话，
|
w**z
发帖数: 8232 | 23 .m2
【在 T*******x 的大作中提到】
: settings.xml在哪个目录里？
:
: which
|
T*******x
发帖数: 8565 | 24 好的谢谢。
maven看了好几次一直没有下决心学明白。有机会好好看看。
override
【在 g*****g 的大作中提到】
: 你看到的这些文件是从远端repository当下来的。conflict是在 client端解决的，不
: 是server端，server只是个repository.
: 解决conflict缺省就是最简单的用靠后的版本，但你可以对每个dependency override
: 和exclude。你应该找个tutorial读一下，光问问题是问不明白的。
|
w**z
发帖数: 8232 | 25 pom.xml 不是自动生成的。upload jar 時带着的。
【在 T*******x 的大作中提到】
: 谢谢。
: 我在maven local repository (.m2)里找到了spring-context所在的目录，
: 里面主要有两个文件，一个是spring-context.jar，另一个是spring-context.pom。
: jar里面没有dependency信息，这些信息是在pom文件里。
: 也就是说，maven central repository网站，
: 对每一个jar文件都整理了一个pom文件，其中存贮它的dependency。
: 所以maven解决类库conflict最终是靠central repository网站维护。
: 对吧？
: maven我一直没搞明白，觉得很confuse。
: 比如这个spring-context类库，我如果不用eclipse工具看的话，
|
