Difference between revisions of "Dynamic Build Languages"

From CitconWiki
Jump to navigationJump to search
(Removed spam)
 
(12 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
ricboccpasmo
 +
relrelnolib
 
''"Harnessing the power of magic..."''
 
''"Harnessing the power of magic..."''
  
Line 40: Line 42:
 
** once it gets really big you need to be able to reason about 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
 
** tests could allow you to refactor/optimise/etc without breaking anything
 +
** testing is much simpler with a real language
 +
*** if you're stuck with ant you could use antunit (http://ant.apache.org/antlibs/antunit/)
 
* we really need a first class language for flexibility
 
* we really need a first class language for flexibility
 
** programming in xml doesn't make sense
 
** programming in xml doesn't make sense
Line 51: Line 55:
 
** what changed? do it anyway not optimal speed
 
** what changed? do it anyway not optimal speed
 
* auto checking of timestamps
 
* auto checking of timestamps
 +
 +
=== raven ===
 +
 +
* java builds using rake and gems
 +
** http://raven.rubyforge.org/
 +
* Book just released
 +
** http://www.apress.com/book/bookDisplay.html?bID=10333
  
 
= Deployment tools =
 
= Deployment tools =
Line 73: Line 84:
 
* http://www.iseff.com/2007/03/capistrano-and-java.html
 
* http://www.iseff.com/2007/03/capistrano-and-java.html
 
* http://www.oreillynet.com/ruby/blog/2007/04/capistrano_20_not_just_for_rai.html
 
* http://www.oreillynet.com/ruby/blog/2007/04/capistrano_20_not_just_for_rai.html
 +
* http://www.smartfrog.org - SmartFrog is a technology for describing distributed software systems as collections of cooperating components, and then activating and managing them. It was developed at HP Labs in Bristol, in the UK. The core SmartFrog framework is released under LGPL.

Latest revision as of 01:28, 1 November 2007

ricboccpasmo relrelnolib "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
    • testing is much simpler with a real language
  • 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

raven

Deployment tools

Capistrano for Java deployment?

  • posix only (no windows yet)
    • installing cygwin is a solution
    • write adapters for the commands used (ssh, ftp, etc)
  • version 2.0 just released
  • peepcode demo (http://topfunky.com/clients/peepcode/free-episodes/peepcode-free-deprec.mov)
  • 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
    • ask for forgiveness rather than permission

Links