Difference between revisions of "Dynamic Build Languages"

From CitconWiki
Jump to navigationJump to search
Line 59: Line 59:
 
** installing cygwin is a solution
 
** installing cygwin is a solution
 
** write adapters for the commands used (ssh, ftp, etc)
 
** write adapters for the commands used (ssh, ftp, etc)
* peepcode demo
+
* peepcode demo (http://topfunky.com/clients/peepcode/free-episodes/peepcode-free-deprec.mov)
 
** building ubuntu box remotely via ssh
 
** building ubuntu box remotely via ssh
 +
** using the deprec gem (http://www.deprec.org/)
 
* convincing management that using a Ruby tool on a Java project is a good thing
 
* convincing management that using a Ruby tool on a Java project is a good thing
 
** it's often easier to just do it and show the benefits
 
** it's often easier to just do it and show the benefits
 
** ask for forgiveness rather than permission
 
** ask for forgiveness rather than permission

Revision as of 22:28, 28 July 2007

"Harnessing the power of magic..."

Facilitated by Josh Price and Tom Adams

Build Tools

What's the current state of Java build tools?

Performance is not always optimal.

ant

  • programming in xml doesn't make sense
  • big ball of ant problem
    • the 9000 line "untouchable" collection of build script
  • few conventions
    • lots of rope to hang yourself
  • hard to refactor
  • ill-conceived
    • even JDD has disowned it

maven

  • good conventions but hard to diverge from the norm
    • simple things are simple
    • moderate things are really hard (write a plugin)
    • hard things are virtually impossible
  • too much voodoo
  • not enough docs
    • hard to find where/how to configure things
  • kind of buggy
    • (I think this was attributed to plugins)
  • declarative model is too strict
    • flexibility is needed here
  • appeals to the less experienced
    • can get yourself in trouble if you assume it all just works

What can Java learn from Ruby?

rake

  • testing your build?
    • once it gets really big you need to be able to reason about your build.
    • tests could allow you to refactor/optimise/etc without breaking anything
  • we really need a first class language for flexibility
    • programming in xml doesn't make sense
    • pure declarative model solves some problems but reduces flexibility
  • auto include of rake files allows easy factoring
  • possible to separate the definition of dependencies - who depends on me?
  • builtin namespaces (ie db:*, test:*)
  • plugins in ruby are really simple
    • monkey patching
  • file dependency checking is built in
    • what changed? do it anyway not optimal speed
  • auto checking of timestamps

Deployment tools

Capistrano for Java deployment?