James Strachan wrote:
>
> From: "Glen Stampoultzis" <[EMAIL PROTECTED]>
...
>>I'd be interested in learning more about what problems you believe Jelly
>>solves that Ant was unable to.
>
>
> We tried using Ant for 'callbacks' so that users can provide custom
> project-specific logic inside a shared Maven build and it sucked. With Jelly
> we can use the Werkz library to provide very flexible goal orientated builds
> where we can attach custom logic as pre/post conditions, perform pre/post
> actions or goals which makes it very easy to perform custom logic inside the
> Maven build. So now we have a very flexible mechanism to reuse a global
> Maven build while individual projects can now easily override each step or
> add pre/post processing easily.
Which is exactly what we want to avoid.
Pre and Post are used for decorating an existing build, ie enhancing
present functionality.
Instead, we define /features/ centrally, and specify the sequence of
"goal" to attain to have that feature.
Let's assume you have a docs goal, with pre-goal and post-goal.
What's the order in which you run the pre and post goals?
A sequence I assume.
Taking for granted that I wouldn't want to use the default goal itself,
I could simply do:
<feature name="docs">
<pre1/>
<pre2/>
<docs/>
<post1/>
<post2/>
</feature>
No need of pres and posts.
> So out of the box a Maven project doesn't even need a build.xml file, Maven
> knows what to do. If a project wants to add some custom targets or customize
> how things get built, they can create their own project-local maven.xml
> file.
This is not a big feature; I can just give you a standard build.xml to
use and it has the same effect.
If I want to hide it I can put it in a jar, no problem.
That we don't want.
> Another help is that Jelly supports a Velocity-style expression language
> (Jexl) so in Jelly script we can actually pull information from the Maven
> project object model beans and populate the necessary Ant tasks, or perform
> decent boolean logic or looping etc. We're not restricted by a flat
> properties file like Ant is.
Jelly is for scripting, Ant for building.
If you need to script in Ant, just use the Jelly task.
Using Ant to script is the problem, not Ant itself.
There are tasks that make you svript in Javascript, which is far more
expressive than Jelly.
> Jelly also supports a concept called 'Jelly Beans' whcih allow any bean to
> be bound to a tag, a little like Ant's <taskdef> but without the limitation
> that it must be an Ant task or understand an Ant Project. So any bean,
> Runnable object can easily be bound and scripted in a Jelly build file
> making the development of plugins easier.
I can make a BeanTask in Ant to do the same, but I don't see benefits in
using beans directly in the build process.
You are talking about scripting, not targets-tasks.
> Jelly has a flexible include mechanism so that build files can be refactored
> and reused easily. Also Jelly supports the use of custom macros, so common
> tasks can be wrapped up in new tags to avoid repetitive typing and avoids
> verbose build files.
Same in Ant, with antcall.
Now the new <import> tag.
It does the same, but I only wrote 30 lines of code ;-)
> Finally Jelly is capable of running all Ant tasks, so nothing is lost by
> using Jelly instead of just vanilla Ant - all investment in Ant technology
> is preserved. Note also that Maven will be autogenerating a build.xml
> document that can be used by 'vanilla Ant' and Gump, so regular Ant or Gump
> users will still be able to build the project even if they don't want the
> full power and feature set of Maven.
You lose the knowledge of how builds are created, and ask users to
understand Jelly.
If we don't need pre and post tasks, like in Centipede, there is no need
of making Jelly central versus Ant central.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
