James Strachan wrote:
> From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]>
>
>>James Strachan wrote:
...
>>>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.
As I said, callback are not needed.
Each plugin should be indipendent and not require other plugins; this
make it easier to reuse and not dependent on other stuff.
Each target can say that it can partecipate in a feature, and that it
can use stuff created by other features.
>>>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.
;-)
We don't think about sharing build.xml, but doing the opposite, by
sharing the common parts. We "import" common stuff, instead of trying to
force common behaviour to change with callbacks.
As you see, we are not trying to do what you say.
What is required by many is not that subbuilds decorate the common
parts, but that common pre and post targets decorate each costomized part.
It's the other way round.
>>>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.
Users ask for Ant.
If I say that I have something that is alpha, but can run Ant buildfiles
with additional stuff that is cool but not *that* important, guess
what users will choose.
I did propose to use Jelly, but got negative feedback from the users and
other developers, because it creates more problems that it solves.
We call it FS, Flexibility Syndrome.
>>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.
That's why Centipede has ant-contrib OOTB, with the <if> and the
<for-each> tags.
And there is also no need to write an external file for expressions:
javascript is available already for quite some time.
There is no real technical reason why Jelly tags cannot be inlined the
<jelly> ant task tag.
>>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'.
Any tool is inflexible if you don't know how to use it.
>>>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?
? Plugins for me are tasks+targets.
The targets and tasks themselves can contain scripts.
As I said, I don't mind having targets with parts written in Jelly, I
just don't have the need of using it for the overall build process.
>>>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.
Nope, RTM. That's <ant>
> Its not a macro and
> doesn't help keep verbosity down; if anything its the converse.
<import>+<taskdef>+<antcall>
>>Now the new <import> tag.
>
> Sure thats a step in the right direction.
Yup.
>>It does the same, but I only wrote 30 lines of code ;-)
>
> Thats a lot more lines than the include tag in Jelly :-)
But you had to write Jelly :-P
>>>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.
Werkz? Goals? pre-post?
These are new concepts.
>>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.
Yes, a totally different approach.
In a sense the opposite, since we want to make it easy to compose a
build with pre-made components while Maven want to change a common build
with callbacks, which is a bit convoluted, IMO.
We use composition, you use inheritance.
I favor composition when possible, this is a generally known and
accepted good programming practice, especially when what you are
creating "contains-a" rather than "is-a".
> Then Jelly, Maven or
> vanilla Ant users could reuse Centipede's Ant tasks, then we all win.
Sure.
Centipede then will use Maven's plugins as tasks.
But to write plugins you need to learn new stuff, to write cents, just
plain Ant.
--
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]>
