Hi Glen From: "Glen Stampoultzis" <[EMAIL PROTECTED]> > > [EMAIL PROTECTED] wrote on 07/02/2002 05:35:44 > PM: > Glenn Stampoulis writes: > >> Ant has has few limitations as a build system. It does tend to bog down > for > >> complicated builds. Just look at the hoops you have to go through to do > >> conditional logic so I guess I can understand why Maven might have headed > in > >> that direction. Whether it's going to turn out to be a good move remains > to > >> be seen. Ant has a large established userbase with a large range of > really > >> nifty ready to use tasks. > >The good thing about Jelly is that it can also execute Ant scripts. > > 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. 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. 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 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. 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. 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. James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
