+1 for Jelly then. This sounds really good. ----- Original Message ----- From: "James Strachan" <[EMAIL PROTECTED]> To: "Turbine Maven Users List" <[EMAIL PROTECTED]>; "Glen Stampoultzis" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, July 04, 2002 11:36 AM Subject: Re: [Centipede] Final proposal
> 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
