Difference between revisions of "Dynamic Build Languages"
From CitconWiki
Jump to navigationJump to search| Line 6: | Line 6: | ||
== What's the current state of Java build tools? == | == What's the current state of Java build tools? == | ||
| + | |||
| + | Performance is not always optimal. | ||
=== ant === | === ant === | ||
| − | * programming in xml | + | * programming in xml doesn't make sense |
| − | * big ball of ant | + | * big ball of ant problem |
| − | * few conventions lots of rope to hang yourself | + | ** the 9000 line "untouchable" collection of build script |
| + | * few conventions | ||
| + | ** lots of rope to hang yourself | ||
* hard to refactor | * hard to refactor | ||
| − | * ill-conceived | + | * ill-conceived |
| + | ** even JDD has disowned it | ||
| − | == maven == | + | === maven === |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
* good conventions but hard to diverge from the norm | * good conventions but hard to diverge from the norm | ||
| − | * declarative model is too strict | + | ** simple things are simple |
| − | * appeals to the less experienced | + | ** 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 == | + | === rake === |
* testing your build? | * testing your build? | ||
| − | * need a first class language | + | ** once it gets really big you need to be able to reason about your build. |
| − | * file dependency | + | ** 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 | * auto checking of timestamps | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | = | + | = Deployment tools = |
| − | + | == Capistrano for Java deployment? == | |
| − | |||
| − | * convincing management | + | * posix only (no windows yet) |
| + | ** installing cygwin is a solution | ||
| + | ** write adapters for the commands used (ssh, ftp, etc) | ||
| + | * peepcode demo | ||
| + | ** building ubuntu box remotely via ssh | ||
| + | * 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 | ||
Revision as of 18:05, 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?
- posix only (no windows yet)
- installing cygwin is a solution
- write adapters for the commands used (ssh, ftp, etc)
- peepcode demo
- building ubuntu box remotely via ssh
- 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
