From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]> > 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.
Sure, if your build is as simplistic as the above then that mechanism works fine in both Ant and Jelly. When you have a full build of multiple inter-related goals/features with interrelated dependencies using the above simplistic model has many limitations, which we've been through on the Maven project. This is exactly why we stopped using Ant for callbacks - its much too painful for non-trivial stuff. > > 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. Sharing the same build.xml is not a big win - its being able to easily and fully customize the common build, thats the win. We've found that Jelly makes this *much* easier than using Ant. Good look trying to use Ant for this. > > 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. Huh? Jelly can run exactly the same build.xml files from Ant plus has some new features. So Jelly can be for building too. > If you need to script in Ant, just use the Jelly task. Sure though its a bit more verbose to break down to scripts every time you just need an expression, some value or just loop over some Ant 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. Sure you can script in JavaScript in Jelly too if thats what you need. I don't buy this argument that Ant has to be inflexible and have crappy expressions & conditions & no looping just because its for 'building'. > > 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. I'm talking about integrating plugin code; which doesn't have to be an Ant Task. This is about building not scripting isn't it? > > 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. That just invokes a target in another build file. Its not a macro and doesn't help keep verbosity down; if anything its the converse. > Now the new <import> tag. Sure thats a step in the right direction. > It does the same, but I only wrote 30 lines of code ;-) Thats a lot more lines than the include tag in Jelly :-) > > 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. How? Users really only understand what the XML should look like to get things done. Jelly doesn't change that at all - we just add some extra XML tags and expresssions that they can use, in addition to their current Ant knowledge. Like I said, we're preserving all investment in Ant - we're just enhancing it. > If we don't need pre and post tasks, like in Centipede, there is no need > of making Jelly central versus Ant central. It certainly sounds like Centipede is better built as a bunch of Ant tasks since its taking a totally different approach to Maven. Then Jelly, Maven or vanilla Ant users could reuse Centipede's Ant tasks, then we all win. 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]>
