cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject On the subject of builds strategies...
Date Tue, 25 May 2004 13:46:41 GMT
I am forwarding this message from Niclas Hedhman to the Avalon team.
In essence, it is a project born out of lessons learned.  If you are
interested, great; if not, no skin off my nose.  He does have some
good points in that thread.

On a related note, I know Leo Simons has put together an ANT task
to download from a Maven style repository the library you may want.
If it wasn't a task, it was an imported build file--either way, he
mentioned it was an elegant way to to get the JAR files you need
without keeping them in CVS.  This approach leverages ANT and could
probably be included into the Cocoon build process with minimal effort
or risk.

-----------  Forwarded from Niclas Hedhman at Avalon ----------------

MAGIC - Magic Ain't Gonna Interest Critics

Magic is an experimental build system that I have been working on for a 
of days.

What is it?

Magic is a generic build system, influenced by both the good parts as 
well as
the bad parts of Maven;
   -  Plugins are good.
   -  Standard build layouts are good.
   -  Downloadable artifacts are good.
   -  Automatic dependency resolution is good.
   -  Scripting can(!) be convenient.
   -  preGoal/postGoal can be useful.
   -  Ant is an incredible collection of well-tested code.
   -  XML is not for programming language syntax.
   -  Why do I need to know another programming language than Java?
   -  XML is slow to parse.
   -  Don't mix Ant XML with other XML.

Once Magic is built and 'installed', it is a command-line utility which is
invoked with the command 'magic'.

Magic is small. The engine Jar file is <20k.

Magic is fast. Practically no overhead at all. Most processing on-demand 

Magic uses partial Avalon Framework for the scripts, namely 
Contextualizable, LogEnabled, Serviceable and Initializable.

Magic leverages the BeanShell scripting interpreter (which is also 
fairly small ~150k).

Magic can build and install BeanShell script plugins, which makes up the
complete build system. Currently, I have created; plugin, prepare, 
artifact, java, jar and xdoc plugins.

Magic allows the programmer to add their own build.bsh scripts at each 
project for specialized processing.

Magic has a properties file chain, for multi-level overrides.

Magic knows about projects sharing a common higher level system, so 
called "Project System".

Magic has a powerful and flexible, yet simple, notification system, that
handles preGoal/postGoal constructs.

What is it NOT?

Magic is not perfect.

Magic is not complete, or intend to compete with the breadth of plugins 
for Maven.

Magic is not bug-free.

Magic is not optimized at all. Just happened to be fast be design.

Magic is not necessary going to become a proper product/project, only an
experiment at this stage.

Magic is not going to replace Ant.

Where is it?
Magic is checked into the Avalon subversion repo, under tools/magic, and 
it also requires the system/ directory, which contains all the 
definition and dependency files. system/ is the 'Project System".
legacy/avalon/framwork/api has been updated with a 
file, to allow Magic to build it (which takes 3secs on my machine 
without the download).

How do I build and test run it?
0. You need to run on Linux, or create your own .bat file equivalent to 
the 'magic' one. You will also need Ant and JDK 1.4 or later.
1. Make sure you have BeanShell 2.0b1 in your Maven repository, under 
the id bsh.
2. go to tools/magic/engine
3. run "ant"
4. add the directory tools/magic/engine/target/dist/bin to your PATH.
5. go to tools/magic
6. run "magic build"  -  This will validate and install the plugins.
7. go to legacy/avalon/framework/api
8. run "magic java.compile" or "magic jar.jar"

What will happen next?
Features that I will add over the next few days (not necessarily in this
  *  JavaDoc plugin.
  *  Unittesting with reporting.
  *  Fix up so that the xdoc plugin works (now missing some jars in 
  *  Filtering in source copying.
  *  Better handling of Site xdoc aggregation in the xdoc plugin.
  *  Add xdocs to the existing plugins.
  *  Some simple sequencing mechanism.
  *  Better error handling.
  *  Better Logging solution, currently a hardcoded ConsoleLogger.

I will try to entertain any feedback received, but please be realistic 
about any feature requests. I will try my best to get you going, and 
explain how one can write plugins, and how the system hangs together.

I hope someone will find the experiment interesting, and as the acronym
suggests, I will not entertain people who only wishes to piss on the 
'bad things', I have better things to do than convince people with 
opinions :o)


   /        /
  / /

View raw message