|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-06-30
crmky 写道 我认为build tool的关键价值在其提供了许多常用的任务模板，Ant的缺陷就在于组装这些模板时不太方便。只要任务模板足够丰富，用啥实现都无所谓，script也好，java也好。
常用模板是最重要的功能，但并不是难度最大的。基本上就是体力活，把无数的Task插进系统就ok了。这方面ant做的相当好了。ant的欠缺，就是表达逻辑流程等东西。 crmky 写道 象我这种懒人，既然已经会了Ant，而且大部分我希望build tool能解决的问题ant都能比较好的解决，我是懒得再去学其他的玩意。 这是一个问题。Neptune最大的缺陷就在于你需要学一个新的语言。 crmky 写道 如果我不会Ant，但是会java，我希望的解决方式类似于： JavacTask javac = new JavacTask();;
javac.setClasspath(...);;
javac.setFork(...);;
javac.execute();;
JUnitTask junit = new JUnitTask();;
...
Task能解决的东西就交给Task解决，Task不能解决的东西，如流程判断等等就交给java语言本身来解决，也不用怎么学习新的东西。再说了，IDE还能提供自动完成哩 
不明白你的意思。你上面的代码用xml或者脚本都可以很好的描述，ant描述它玩儿似的。用脚本，也不过是： javacTask = javac {classpath="...";fork=...;...}
好像也简单得很。 我前面提出的问题，是处理task之间的交互以及代码重用，你可以试着用java写写这种逻辑（比如从两个task取得结果，逻辑判断，根据判断结果决定下面调用哪个task这种） crmky 写道 再其次，就是一种学习新的script语法，啥时候再出来新玩意就再去学…… 最惨的，就是重头开始，自己一个一个实现每种任务…… 不会让你实现任务的。这个工具作出来，必然会包含大多的任务。而且，最终应该可以让它直接调用ant。 crmky 写道 我建议如果真的要做这个项目，还是在Ant外面套一个script的壳比较好，可以调用壳自己提供的任务或是Ant任务，比Ant好的地方就在于语法和流程控制，也许比较容易推广。 一样的。大家的问题其实不在底层是直接调用ant还是直接写的task，而是对这个作为壳的脚本有意见。 当然，为了节省开发的力气，我也在看是否能够直接调用ant的类来直接adapt出来Neptune需要的很多task。 如果谁对ant的代码很熟悉，希望能帮帮-忙？ |
| 返回顶楼 | |
|
发表时间：2005-06-30
firebody 写道 ajoo
看了你那段位代码脚本，我不得不打击你一下。 实在是很难看。 似乎命令脚本可以带来工作效率的提高，但是其也有很多不足的地方，比如复杂的格式语法，缺乏必要的语法检查... 给你一个Task接口，以及相应的ant meta info Object。你可以用java做你想做的任何事情。至于因为你做的逻辑比较复杂而带来繁琐的代码，那时你的应用问题，而不能怪及到ant身上吧。 其实，这个脚本确实不如haskell语言。在haskell中，会是这样： auto (info.println "build done"); $
do
time<-now
info.println ("build starting at " + time);
t1 <- readFile "file1"
t2 <- readFile "file2"
let diff = t2 - t1
writeFile "file3" diff
很多的$, >>等符号都可以省略去了。但是整体并没有变。 我的脚本的语法就是尽量逼近上面的haskell语法写的，惭愧的是，没有达到haskell的简洁程度。 可惜我不知道是否有能够直接调用java的haskell脚本。 不过，说比xml难看，为了公平起见，建议你们自己拿xml把同样的逻辑写一遍在说。 据我所知，xml要不根本做不了同样的事情，要不就是繁琐异常。 至于说后面那段话，我只能理解为，你根本没看到跨越task之间的组合，分支等的意义。 用java来实现Task没问题，但是这种方法只适用于实现原子Task，要是你想用它来组合task，建议你自己写写再说。 |
| 返回顶楼 | |
|
发表时间：2005-06-30
毕竟流程控制在build中用的很少,原来ant那些简单的task用xml描述其实挺好的(一般都是复杂粘贴现成的,再改改参数),这类task也换新的脚本来写,大概会叫苦了.
|
| 返回顶楼 | |
|
发表时间：2005-06-30
robbin 写道 非常高兴看到ajoo的精彩帖子，与我心有戚戚焉！
我一直非常讨厌ant的xml格式的build文件，也一直呼吁，不要用xml去写带有控制逻辑的东西，带有逻辑的东西应该交给script来完成。 ajoo从jaskell脚本，到yan container，现在到build tool，一步一个脚印，在Java平台上面尝试使用script的方式去做各种事情，虽然我没有能力参与ajoo的项目，但是希望能够在宣传上面贡献一把力量。 谢谢谢谢，过段时间，我的yan container的web host弄好了，还要麻烦你多多捧场呢。 
|
| 返回顶楼 | |
|
发表时间：2005-06-30
nihongye 写道 毕竟流程控制在build中用的很少,原来ant那些简单的task用xml描述其实挺好的(一般都是复杂粘贴现成的,再改改参数),这类task也换新的脚本来写,大概会叫苦了.
是啊。描述单个的task，ant足够好了。 不过，脚本也不差呀。 <javac includes="..." excludes="..."> <classpath = .../> </javac> 换成脚本： javac {includes=...; excludes=...; classpath=...}
仍然简单。 ant只能处理简单情况，而脚本对简单需求同样简单，对复杂需求支持更好，也可以节省很多copy-past（这应该用的不少吧？），何去何从呢？ 关于学习代价，如果我们在脚本里面提供直接调用某个ant task的功能呢？ |
| 返回顶楼 | |
|
发表时间：2005-07-01
引用 javac {includes=...; excludes=...; classpath=...}
这样的一段脚本, 我感觉其实只需要写一个结合了Javascript的小工具, 调用Ant的对象模型就可以做了, 所以大家提到的这个基于脚本的build tool完全可以作为Ant的一个扩展来搞, 根本没必要另起炉灶(当然, 也可以不是基于Ant 的, 哪位有信心可以考虑基于脚本实现Maven的功能) 另外需要注意的是Ant不仅仅是一堆Task的集合, 还有诸如对 basedir, properties, fileset, PatternSet 等等的支持, 所以我认为这个build tool不象有些人想的那么简单了, 呵呵, 还是一句话, 干嘛不基于Ant(或者Maven)? |
| 返回顶楼 | |
|
发表时间：2005-07-01
glassprogrammer 写道 引用 javac {includes=...; excludes=...; classpath=...}
这样的一段脚本, 我感觉其实只需要写一个结合了Javascript的小工具, 调用Ant的对象模型就可以做了, 所以大家提到的这个基于脚本的build tool完全可以作为Ant的一个扩展来搞, 根本没必要另起炉灶(当然, 也可以不是基于Ant 的, 哪位有信心可以考虑基于脚本实现Maven的功能) 另外需要注意的是Ant不仅仅是一堆Task的集合, 还有诸如对 basedir, properties, fileset, PatternSet 等等的支持, 所以我认为这个build tool不象有些人想的那么简单了, 呵呵, 还是一句话, 干嘛不基于Ant(或者Maven)? 另外一个问题是：为啥非要基于ant？为啥maven不基于ant？ 其实，你要是仔细看了前面的关于task组合的介绍，就不会问出这种问题了。 javac{...}这种东西，我也说了，和ant没有太大差别。这个build tool的优势也不在这里。我只是用这个例子来说明，对这种简单的需求，它也并不比xml复杂。 而脚本的真正优势在于表达逻辑，在于组合各种task。 当然，如果你认为这种东西可以在ant的基础上来搞，我鼓励你试试。如果你做出来，到真是广大程序员的福音了呢。 不过，真正动手做了或者想了，也许你就会发现ant的局限不是简单弄个script扩展就可以搞定的。 借用你的话：这种组合功能不像有些人想的那么简单。（或者你根本就没想过？） 关于pattern set等等东西，你是在质疑脚本语言的表达能力吗？ 不过我可以告诉你，xml能够表达的东西，用这种函数式的脚本表达只会更简单。 |
| 返回顶楼 | |
|
发表时间：2005-07-01
groovy本身有对ant的包装，也是脚本化的
看起来也挺清爽的 ajoo不妨先看一下，然后指出你设想中的工具更强大的地方 顶楼的文章中的“类groovy脚本”其实更像java一点 groovy中是用closure的 [url] http://groovy.codehaus.org/Ant+Scripting [/url] |
| 返回顶楼 | |
|
发表时间：2005-07-01
Mmm,
我的想法是用Command pattern来描述任务和target。 而groovy ant似乎是直接执行ant task了。 这似乎也没什么不妥。我还要仔细想想。 有一个问题：你贴得例子中都是调用ant task，那么怎么用groovy来定义target？ 简单定义好办，就是定义函数好了。 问题是怎么定义dependency? 就是那个著名的depends="task1,task2" 最后，非常感谢你贴得这个连接，我得好好想想我的方法和groovy的方法的优缺点了。 |
| 返回顶楼 | |
|
发表时间：2005-07-01
ajoo 写道 我前面提出的问题，是处理task之间的交互以及代码重用，你可以试着用java写写这种逻辑（比如从两个task取得结果，逻辑判断，根据判断结果决定下面调用哪个task这种） 我的那段代码的确没有描述清楚我所要表达的意思。 为什么这段代码难看？ ajoo 写道 new BoundCommand(
new GetTimeCommand();,
new CommandBinder();{
public Command bind(Object v);{
final Command c2 = new PrintCommand("build time is "+v);;
final Command javacc = new JavaCCommand();;
final Command done = new PrintCommand("build successful");;
return new SeqCommand(c2, new SeqCommand(javacc, done););;
}
}
);;
我认为就是因为过于试图用OO去包装这些流程。至于流程控制就用java语言的流程控制不是更好吗？为什么在流程控制方面还试图去包装成command呢？ 所以我认为 crmky 写道 Task能解决的东西就交给Task解决，Task不能解决的东西，如流程判断等等就交给java语言本身来解决，也不用怎么学习新的东西。
至于用什么实现，是无关紧要的，Build tool最重要的就是提供众多的可重用Task组件，将这些组件组装起来可以利用语言本身的功能，比如可以用java里面的if/ while/try等等，或者如果用其他的脚本语言实现，也可以用那种语言本身提供的这些语法。 BTW，我还认为Command接口的execute不应该返回Object，因为要手工转型（比如你不知道javac的command会返回一个什么样的object），倒不如这样实现： JavacCommand javac = new JavacCommand();; javac.set...; javac.execute();; javac.getCompiledFiles();; javac.get...; 感觉会比 JavacCommand javac = new JavacCommand();; javac.set...; Object obj = javac.execute();; 到底将obj转成什么对象呢，要去查javadoc 会好一点 |
| 返回顶楼 | |
