You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Tim O'Brien <tm...@mindspring.com> on 2000/06/27 17:39:55 UTC
proposing TaskUtil.java
I've noticed that Ant might benefit from a TaskUtil class that would contain
static utility functions for taskdefs. One function that would benefit the
project as a whole would be a function to read multiple inputs, I see this
has been duplicated a number of times already,. In the documentation, we
could outline all utility functions for people who wish to extend Ant.
Also, I see that some tasks are using Project.resolveFile() for file
resolution and some are not. I take it that the standard is to use
resolveFile().
Tim O'Brien
tobrien@ieee.org
RE: proposing TaskUtil.java
Posted by Peter Donald <do...@mad.scientist.com>.
At 11:31 28/6/00 -0400, you wrote:
>What would you prefer:
>
><available classname="org.whatever.MyClass,org.whatever.MyClass2"
>property="myclasses.present"
>/>
egad runaway runaway. What happens when you have package names as long as I
do and want multiple classes. You end up with somethink like
<available
classname="org.entaka.telanon.core.base.test.KernelTest,org.entaka.telanon.c
ore.jndi.test.ContextTest"
property="myclasses.present"/>
ugly ! and difficult to read IMO.
><available property="myclasses.present">
> <resource classname="org.whatever.MyClass"\>
> <resource classname="org.whatever.MyClass2"\>
></available>
I like this much better although there is also an alternative which is
equally readable. Namely
<available property="myclasses.present.1" classname="org.whatever.MyClass" />
<available property="myclasses.present.2" classname="org.whatever.MyClass2" />
<available property="myclasses.present"
available="myclasses.present.1,myclasses.present.2" />
This also has an advantage if you have multiple availables in a hierarchial
tree it all works great :P.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: proposing TaskUtil.java
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "TD" == Tom Dimock <ta...@cornell.edu> writes:
TD> Should the inner tag be <resource classname="whatever"/> or
TD> <class name="whatever"/>?
I'd prefer <class> or <resource:class> over distinguishing between the
different cases via attributes.
Stefan
RE: proposing TaskUtil.java
Posted by Tim O'Brien <tm...@mindspring.com>.
I think that Peter Donald effectively solved/ended this thread earlier
today. The concept that multiple inputs to taskdefs combined in one input
string should be avoided when unnecessary is a good design guideline to
follow.
Tim O'Brien
tobrien@ieee.org
-----Original Message-----
From: Tom Dimock [mailto:tad1@cornell.edu]
Sent: Wednesday, June 28, 2000 12:49 PM
To: ant-dev@jakarta.apache.org
Subject: RE: proposing TaskUtil.java
At 11:31 AM 06/28/2000 -0400, Tim wrote:
>What would you prefer:
>
><available classname="org.whatever.MyClass,org.whatever.MyClass2"
>property="myclasses.present"
>/>
Ugly, becomes very difficult to read if the list gets very long.
><available property="myclasses.present">
> <resource classname="org.whatever.MyClass"\>
> <resource classname="org.whatever.MyClass2"\>
></available>
Much more readable. Should the inner tag be <resource
classname="whatever"/> or <class name="whatever"/>? The latter would seem
to allow for fairly straightforward extension to other resource types. Or
maybe
<available property="myclasses.present">
<resource.class name="org.whatever.MyClass"\>
<resource.class name="org.whatever.MyClass2"\>
</available>
which retains the extensibility, but still makes it clear that this is a
resoucre check...
----------------------------------------------------------------------------
Tom Dimock ---- Cornell University ---- tad1@cornell.edu
"There go my people. I must follow them, for I am their leader." M. Gandhi
RE: proposing TaskUtil.java
Posted by Tom Dimock <ta...@cornell.edu>.
At 11:31 AM 06/28/2000 -0400, Tim wrote:
>What would you prefer:
>
><available classname="org.whatever.MyClass,org.whatever.MyClass2"
>property="myclasses.present"
>/>
Ugly, becomes very difficult to read if the list gets very long.
><available property="myclasses.present">
> <resource classname="org.whatever.MyClass"\>
> <resource classname="org.whatever.MyClass2"\>
></available>
Much more readable. Should the inner tag be <resource
classname="whatever"/> or <class name="whatever"/>? The latter would seem
to allow for fairly straightforward extension to other resource types. Or
maybe
<available property="myclasses.present">
<resource.class name="org.whatever.MyClass"\>
<resource.class name="org.whatever.MyClass2"\>
</available>
which retains the extensibility, but still makes it clear that this is a
resoucre check...
----------------------------------------------------------------------------
Tom Dimock ---- Cornell University ---- tad1@cornell.edu
"There go my people. I must follow them, for I am their leader." M. Gandhi
Re: proposing TaskUtil.java
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "TO" == Tim O'Brien <tm...@mindspring.com> writes:
TO> let me ask a specific question about the patch I submitted on
TO> Available.java. I submitted a patch that allows one to check for
TO> the presence of multiple classes.
Yes and I wanted to thank you that you reminded me of that, Tim,
somehow it had fallen off my TODO list.
I even thought about asking you to rewrite it to use nested elements
instead of lists before I read your mail, so yes, I very much would
prefer nested elements.
One additional reason is that a ',' could be part of a filename when
looking for the presence of files - and the same holds true for almost
every separator you might choose.
Stefan
RE: proposing TaskUtil.java
Posted by Tim O'Brien <tm...@mindspring.com>.
Stefan,
Thanks for clearing that up, I just wanted to make sure that
setFile( File ) would not be diminishing the functionality of. Discovering
what the parameter type is through a method object and then translating that
for a task developer is a "Good Thing".
TO> Another function that there is already a need for is a
TO> parseMultiple() function to resolve multiple string inputs.
SB>I don't think I know where a method like this is needed. Which tasks
SB>use multiple String inputs - or are you talking about tokenizing? My
SB>feeling is that all attributes that are comma separated lists would
SB>better be nested elements.
Stefan let me ask a specific question about the patch I submitted on
Available.java. I submitted a patch that allows one to check for the
presence of multiple classes. Something that would be necessary if a task
developer developed a task that needed to test for the presence of multiple
libraries, resources, files.
What would you prefer:
<available classname="org.whatever.MyClass,org.whatever.MyClass2"
property="myclasses.present"
/>
or
<available property="myclasses.present">
<resource classname="org.whatever.MyClass"\>
<resource classname="org.whatever.MyClass2"\>
</available>
Let me know, what the consensus on this is.
Thanks
Tim O'Brien
tobrien@ieee.org
Stefan
Re: proposing TaskUtil.java
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "TO" == Tim O'Brien <tm...@mindspring.com> writes:
TO> Will setFile( File ), be able to handle multiple files?
No, but setFile(org.apache.tools.ant.util.FileList) could.
The basic idea is/was to allow attributes of any Object type that have
a constructor that takes exactly one String.
File does fit this category in a way but the constructor doesn't do
the right thing, maybe use a home brewed version of File that does the
path resolution?
TO> How would ProjectHelper know if the attribute contained a String
TO> or a File?
It doesn't have to. If there is a setFile(File) method in task, assume
the attribute to be a File, if there is a setFile(Integer) assume it's
an Integer ...
TO> Why not just stay with strings and let Task designers decide what
TO> to do with property strings at set time?
If Task designers want to get the original string value, they will
have setFile(String) and no other method with the name setFile.
Just tell them that they could use setFile(File) instead and the
filename resolution would be done automatically - they still have all
options.
TO> Another function that there is already a need for is a
TO> parseMultiple() function to resolve multiple string inputs.
I don't think I know where a method like this is needed. Which tasks
use multiple String inputs - or are you talking about tokenizing? My
feeling is that all attributes that are comma separated lists would
better be nested elements.
Stefan
Re: proposing TaskUtil.java
Posted by Tim O'Brien <tm...@mindspring.com>.
Stefan,
Will setFile( File ), be able to handle multiple files? How would ProjectHelper know if the attribute contained a String or a File?
Why not just stay with strings and let Task designers decide what to do with property strings at set time? It seems like this is the most flexible design, but it necessitates some common functions, one of which is already available in Project.resolveFile(). Another function that there is already a need for is a parseMultiple() function to resolve multiple string inputs.
Tim O'Brien
tobrien@ieee.org
At 12:51 PM 6/28/00 +0200, Stefan Bodewig wrote:
> >>>>> "TO" == Tim O'Brien <tm...@mindspring.com> writes:
>
> TO> Also, I see that some tasks are using Project.resolveFile() for
> TO> file resolution and some are not. I take it that the standard is
> TO> to use resolveFile().
>
>We are going to have attributes that are not restricted to Strings any
>longer - not that far in the future I hope.
>
>As soon as this has been done, let's go out and replace all
>setFile(String) methods with setFile(File) and let ProjectHelper
>invoke this using Project.resolveFile. That's the most consistent we
>could get.
>
>Stefan
Re: proposing TaskUtil.java
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "TO" == Tim O'Brien <tm...@mindspring.com> writes:
TO> Also, I see that some tasks are using Project.resolveFile() for
TO> file resolution and some are not. I take it that the standard is
TO> to use resolveFile().
We are going to have attributes that are not restricted to Strings any
longer - not that far in the future I hope.
As soon as this has been done, let's go out and replace all
setFile(String) methods with setFile(File) and let ProjectHelper
invoke this using Project.resolveFile. That's the most consistent we
could get.
Stefan