Conor MacNeil wrote:
>I have some concerns about this task. It sounds simple but there are a
>number of complexities with such a task.
I think that the simpler something sounds on paper, the harder it will be
to do in 'real life'. :]
>Firstly it will be useless unless it has some API into the Ant core - the
>callTarget method in your example - who will provide that? In Ant-1 you
can
>probably access a lot of things but in Ant-2 that will all change and you
>may be more restricted in what you can do. One thing for sure, the API
>available to tasks *will* change. The script task itself will have some
>similar problems - I'm not sure the extent of them yet.
My plan is to provide a codeTaskFramework.java file along with the task.
It would be something like this:
public class codeTaskFramework extends Task
{
public void execute throws BuilderException()
{
// YOUR CODE FROM THE BUILD.XML WILL GO HERE
}
//--- Convenience methods:
public void callTarget(...)
{
//--- magic for calling a target (potentially version specific)
}
public void getProperty(...)
{
//--- magic for getting a property (potentially version specific)
}
//--- perhaps others as needed.
}
Because this java file will be editable by the user, they can add whatever
conveniences they like to codeTaskFramework
(realizing that if they do so they'll need to keep a copy of the framework
if they move the build.xml to another environment.
Ideally, they wouldn't ever have to touch that file)
If I get this working I'll accept responsibility for maintaining a version
of codeTaskFramework.java that works with each release of ANT.
The code task itself would look something like
public class codeTask extends Task
{
public void execute throws BuilderException()
{
// Check tempTaskFoo.java write date vs. build.xml write date.
// If needed, re-write tempTaskN.java & rebuild tempTaskN.class
// Get an instance of tempTaskN.class
// Call execute on tempTaskN
}
}
>Such a task can create backward compatability issues which we will need to
>consider carefully. In Ant-2 we will need to get the task API tied down
for
>such a task to minimise these backward compatability issues.
I agree that backwards compatibility is a key concern. I'm using
codeTaskFramework.java as an adapter to hide that potential API churn from
the users. Of course, they can write anything they like in execute()
method. If they put something in their own code that breaks from 1 to 2
then they're going to have the problem wether they use my tag or just write
their own custome task. I suspect that the Ant team will be wary of
breaking regular tasks, so I'll try to act like a regular task as much as
possible.
>Also, there are some practical issues. Where are you going to put the
>generated code. Will you do the compile at parse time or execution time?
>Will you cache the generated class? There may be some classloader fun.
My current plan is to make a tree under the cwd like this:
./antTemp
./antTemp/src
./antTemp/classes
Of course, that would be configurable. The src directory would contain the
framework java file and all genereated java code. Obviously classes would
be where the compiled versions go. For temporary classes, building a large
package hierarcy seems wasteful. All compiling and code loading would be
handled when the code tag's execute method is called. I don't mind
re-checking the file up-to-date each time the task is executed and if I
already have the class available I wont need to re-load it. This means
that the code task should be re-executable with out any trouble.
>Overall I'm not sure this is better than just coding an ad hoc task, which
>I'm not much in favour of either. At least that keeps the Java code in
Java
>files.
The way I am proposing still keeps your java in a valid task. If you get
the task like you want in in the code tags, you can go ahead and take the
task out of my temporary directories and use it just like a normal task.
However, using the code in your build.xml means that you don't have to
chase around between multiple files in order to read what the build.xml
does, unless you want to. Also, it allows rapid development of tasks.
Instead of each attempt being a "edit task.java, compile task.java, run
ant, repeat" the cycle becomes "edit build.xml (which you're probably doing
anyway), run ant, repeat". It is a small optimization from this point of
view, but I think it's much better than chasing around a bunch of small
one-off tasks.
My feeling is that most times you need a bit of flow control it will only
be two or three lines. If you are forced to put those two lines in a file
that needs four lines of syntax sugar to be a valid java file plus two
lines of extra build.xml to load and use them, then you're losing the
meaning in the syntax. Especially if you have four or five places that
need to do flow control. If each flow control takes two lines, the current
system requires you to have six file for your build (build.xml,
snippet1.java, snippet2.java, ... , snipet5.java) Doing the work with
in-lined code you only have one file to worry about and makes that file
much more intuitive to read.
Also, this technique means we don't have to include a third party tool to
use the system. A lot of people suggested beanshell, and while I haven't
gotten to look at it closely yet, I'm not sure that every user of ant wants
to have a copy of beanshell added to the distribution. I think Beanshell
and the other interpreters offer quite a lot more power that we need to
implment a code tag.
Of course, the real reason for doing all of this is to add flow control to
ANT without having to try and write flow control statements using XML tags.
I very strongly believe that Markup languages are not flow control
languages. If I were to see flow control being performed in XML by ANT, I
would be sorely disappointed. The resulting code is just not readable.
>Anyway, I think you may want to perform some experiments. If you go ahead
>please be aware that across the Ant-1/Ant-2 boundary it will break.
Thanks for the warning. The design I'm talking about above would be much
less flexible if you hadn't raised that flag. If you guys accept the task,
I'll accept the maintenance.
Jason Henriksen
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Thursday, 17 May 2001 7:36 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: if and unless attributes for all Tasks
>
>
>
> Hi All,
>
> Roger Vaughn and I have been discussing XML as a flow control language
and
> I've come up with a compromise that I'm considering taking a stab at
> writing. I want to bounce the idea off all of you before I invest a pile
> of time into an idea that one of you might be able to easily debunk.
>
> I feel that XML is a very poor language for describing conditionals. All
> the arguments seem to show that. I suggest a new task called 'code' that
> would work something like this:
>
> <target name="make">
> <code>
> if(true){
> callTarget("compile");
> }
> </code>
> </target>
>
> My task would then take all of the Java between the code tags, put it
into
> a TempTaskN.java file, compile it, load the class then call the task just
> like any other. Basically, the code tag is just a scriptlet in the
> build.xml.
>
> To my thinking this has the following advantages:
> - It doesn't break the current design and architecture
> - It takes advantage of the fact that we already have a very nice
> language and compiler,
> we should not have to build another one
> - Because tasks in this context tend to be one-off, non-reusable
bits
> of code, it is
> really nice to keep the task code in the same file as
> the rest of
> the build.
> - The java in the code block could call the other tasks, but still
> have all of the
> flexibility of Java
>
> My most optimistic hope is that I can write this into a regular task, and
> ANT itself would not have to change at all.
>
> Can any of you think of a reason this wouldn't work? If not, I'm going
to
> try coding it next week and I've got some scraps of free time coming.
>
> Let me know what you think, and thank's to Roger for the discussion about
> it.
>
> Jason Henriksen
>
------------------------------------------------------------------------------
Warning : The information contained in this message may be privileged and
confidential and protected from disclosure. If the reader of this message is
not the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you
have received this communication in error, please notify us immediately by
replying to this message and then delete it from your computer. All e-mail sent
to this address will be received by the Providian Financial corporate e-mail
system and is subject to archiving and review by someone other than the
recipient.
==============================================================================
