jstrachan 2002/06/11 03:13:54
Added: xdocs/ref new-design-musings.xml
Log:
added some design musings (sorry I don't know latex ;-) that describes the various
functional areas of Maven and how each bit could be implemented.
This document describes where we can reuse Ant, where we can reuse what we have,
where we could introduce Werkz and where Jelly might have some use.
Please lets all hack this to try add all of our various oppinions on things.
Revision Changes Path
1.1 jakarta-turbine-maven/xdocs/ref/new-design-musings.xml
Index: new-design-musings.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<author email="[EMAIL PROTECTED]">James Strachan</author>
<title>Maven Properties Documentation</title>
</properties>
<body>
<section name="Introduction">
<p>
I just thought I'd try to describe all the various functional areas
and use cases of Maven.
Then we can discuss and hack this document until we reach some sort of
consensus.
Once thats done we can all take a piece of the system and implement it.
</p>
</section>
<section name="Tasks">
<p>
Maven requires a bunch of tasks to be executed for different build
targets.
Reusing the large number of existing Ant Tasks makes a whole lot of
sense since most of
what Maven does is already available right now in Ant tasks, javac,
java, jar, javadoc, junit etc.
Having new non-Ant tasks as just <i>maven beans</i> is certainly
possible for brand new tasks.
</p>
<p>
Current proposal: use Java code, Ant tasks, maven beans.
</p>
</section>
<section name="Goal / target mechanism">
<p>
We need some kind of goal / target dependency mechanism.
This is not just simple depends="compile" stuff in Ant.
We need a flexible way to introduce pre/post action and pre/post dependency
actions
to implement callbacks easily and introduce extra tasks into Maven's process
from user specific
build enhancements.
Bob's <a href="http://werkz.sourceforge.net/";>Werkz</a> looks a good
solution to this problem.
</p>
<p>
Current proposal: use Werkz
</p>
</section>
<section name="Project dependency library">
<p>
We need some kind of cross-project mechanism that can handle multiple JAR
repositories,
flattening dependency trees, handing sub-projects and so forth. What we have
right now is close
but needs some refactoring to support not having to flatten each
dependencies. e.g. we should
be able to say we depend on 'commons-digester' version 1.3 and for Maven to
flatten the dependency tree.
</p>
<p>
Current proposal: use Java code, enhancing what we have
</p>
</section>
<section name="Plugins">
<p>
A plugin seems to be (and correct me if this is wrong)..
</p>
<ul>
<li>one or more build targets, which may have their own dependent
targets</li>
<li>one or more Ant Tasks or maven beans</li>
<li>some glue to populate the tasks/beans with information from user
defined properties files or POM values</li>
</ul>
<p>
Now the first 2 items are trivial. The last one seems a bit
controversial.
I personally prefer an Ant-like XML script to define the Maven
targets, then folks can reuse existing
knowledge in scripting build related tasks (property, javac, java,
javadoc, junit etc). Though this could
also be done in Java code too.
</p>
<p>
Current proposal: use Java code or Jelly script depending on the
developers religion ;-). Both can
easily be integrated together into the Goal / target mechanism
</p>
</section>
<section name="User defined callbacks">
<p>
We need a simple mechanism for users to define their own callbacks so
that users can customize
the default behaviour of Maven, add extra functionality/tasks as well
as creating new goals/targets
which are project specific. We cannot ever hope for Maven to do
everything a project needs so we
need some easy mechanism to extend Maven with something we've called
<i>callbacks</i> up to now.
</p>
<p>
Right now we've been using a complex
mixture of Ant builds, properties to enable a callback and define the
build file, then inside Maven lots
of verbose Ant logic to detect if callbacks are enabled. This is
pretty yukky stuff, makes the
build very slow, causes the build files to be pretty huge.
</p>
<p>
Certainly if Maven's core engine were based on something like Werkz
this would make things much cleaner.
Though how should a user specify some extra <copy> tasks or
whatever they need to do?
</p>
<p>
Users could write Java code to register new tasks.
Though this has problems, there's a chicken and egg situation of
compiling the projects
java code to be able to compile the projects java code. Also ClassPath
issues will certainly arise.
</p>
<p>
Right now most developers use Ant, so an Ant like
XML mechanism would be ideal. Also using Jexl as the expression
language to allow the POM
and Maven beans to be used easily would help too.
This would be my preference as it avoids many of the problems with
using Java code for this
section of Maven and allows current investment in Ant XML
to be reused. For example a new user moving to a Maven build will want
to keep or reuse some of their
current build.xml's code when they port to Maven.
</p>
<p>
There's an example of how this could look in
src/bin/example-userbuild.jelly. Its pretty easy to do,
its probably a couple of hours work to build a really simple
Maven/Werkz tag library.
</p>
<p>
Current proposal: Jelly script or some hacked Ant mechanism.
Jelly is easy, Ant is much harder since its already got the target
baggage.
</p>
</section>
</body>
</document>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
