You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by James Fuller <ji...@ruminate.co.uk> on 2005/02/28 17:57:05 UTC
a few questions (sorry quite long)
btw I have a few general developer questions... before I start caning
bugzilla I think any responses would be well appreciated;
--------------------------------
a few comments on usage of XDoclet to autodoc manual
--------------------------------
as someone who is a complete fan of XDoclet and avid user in enterprise
java computing...I am surprised at myself at having reservations with
its usage in task definitions having a single source from which
documentation is generated is a 'good thing'...esp in defining task, its
attributes, as well as general documentation, but how to deal with other
potential documentation requirements, e.g. if we wanted to we could also
embed build scripts, example input/output, and schema definitions as
well...perhaps there is some traction to be gained by having a simple
task markup language
without thinking....
<?xml version="1.0" encoding="UTF-8"?>
<task name="echo" xmlns:x="http://www.w3.org/1999/xhtml">
<attribute name="message" required="true|false" default="">
<desc>the message to echo.</desc>
<required>Yes, unless data is included in a character section
within this
element.</required>
</attribute>
<attribute name="file" required="true|false" default="">the file to
write the message to.</attribute>
<attribute name="append" required="true|false"
default="false">Append to an existing file?</attribute>
<attribute name="level" required="true|false"
values="error,warning,inf,verbose,debug"
default="warning">Control the level at which this message is
reported. One of "error",
"warning", "info", "verbose", "debug" </attribute>
<block name="description">
<x:p>Echoes a message to the current loggers and listeners which
means System.out unless
overridden. A level can be specified, which controls at what
logging level the message
is filtered at.</x:p>
<x:p>The task can also echo to a file, in which case the option
to append rather than
overwrite the file is available, and the level option is
ignored</x:p>
</block>
<usecase>
<!-- could place example build scripts, along with
inputs/outputs/expected -->
</usecase>
<dependencies>
<!-- if we were smart we would have this in a <getlibraries/>
friendly format -->
</dependencies>
<schema type="relaxng|dtd|xmlschema" href=""/>
</task>
we could use xinclude if we wanted to break things up....also we could
assume that code takes precedent either overwriting, or where no source
comments exist taken from this document for ant manual definition
purposes...I really think given task writers the ability to combine the
power XDoclet and and external task markup format.
Also this format could be impregnated with dublincore for versioning; in
addition we could choose xhtml as an additional format...in any event
the more meta data the better.
-----------------------------------------
a few general comments
----------------------------------------
- getlibraries has no task definition that I can see....correct me if I
am wrong
- exec task has floating html tag in manual
- does scriptdef have namespace capability
- i think its important to make sure developers for for
DispatchTask...its seems to be buried
- note: there is no 2005 copyright in ant manual/docs
- is there a list of @ant.task category types anywhere ?
- is abstractaccess optional task @ant.task category the right way to
use this doc tag? also any list of ant.task category anywhere ?
- couldnt find any logging/listener tests under testcases ?
- MagicNames.java...whats the status and intended purpose ?
- any update on webdav task
--------------------------------------------
some very boring and picky refactoring related thoughts
--------------------------------------------
I see a lot of Ant refactoring opportunities with respect to package
naming...no doubt the twin poles of maintaining backwards compatibility
with cutting edge functionality has caused a bit of chaos in the source
tree.
There are a few methods of mapping old package names (satisfy
deprecated, older calls) to better logical structures...any thoughts re
this ?
if so....then a few suggestions on moving things around;
Why not move things like
-org/apache/tools/launch/Locator to
-org/apache/tools/helper
Why not move
-org/apache/tools/NoBannerLogger, SubBuildListener, XMLLogger to
-org/apache/tools/listener
Why not move ?
-main/org/apache/tools/bzip
-main/org/apache/tools/bzip2
-main/org/apache/tools/mail
-main/org/apache/tools/tar
-main/org/apache/tools/zip
excuse my ignorance here (well if u never ask questions...)....are these
are org.apache.tools packages used by other apache projects
Also in testcases things are a bit messy...for example why not put dummy
into
-testcases/org/apache/tools/dummy
along these lines, I find burying property files can sometimes be
detrimental, for example in main source we have;
-main/org/apache/tools/taskdef/defaults.properties
-main/org/apache/tools/types/defaults.properties
-main/org/apache/tools/listener/defaults.properties
is heritical to move these to somewhere more visible ?
-also quite a bit of property files scattered about testcases...might be
useful to agree on some formalism here
perhaps we could prune
-main.com.ice.tar
-main.com.oreilly.servlet
- why are these tests at toplevel ?
testcases/org/apache/tools/mail
testcases/org/apache/tools/tar
testcases/org/apache/tools/zip
- dont understand why dispatch has its own directory ?
many thx, and many apologies for my naive questions.....I know that (esp
refactorings) there will be backward compatibility issues dominating the
reasons why things exist.
regards, Jim Fuller
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: a few questions (sorry quite long)
Posted by Peter Reilly <pe...@apache.org>.
Stefan Bodewig wrote:
>On Mon, 07 Mar 2005, Peter Reilly <pe...@apache.org> wrote:
>
>
>
>>On my list!
>>
>>
>
>Oh, I can do that as well.
>
Tis done.
> uri should be supported by scriptdef,
>typedef, taskdef, macrodef and presetdef, AFAIK.
>
>
These all have the manual entry.
>Any other task extending AntlibDefinition I'm missing?
>
>
I do not think so.
Peter
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: a few questions (sorry quite long)
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 07 Mar 2005, Peter Reilly <pe...@apache.org> wrote:
> On my list!
Oh, I can do that as well. uri should be supported by scriptdef,
typedef, taskdef, macrodef and presetdef, AFAIK.
Any other task extending AntlibDefinition I'm missing?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: a few questions (sorry quite long)
Posted by Peter Reilly <pe...@apache.org>.
Stefan Bodewig wrote:
>On Wed, 02 Mar 2005, Peter Reilly <pe...@apache.org> wrote:
>
>
>
>>The doc does not mention it, but <scriptdef> inherits attributes
>>from DefBase,
>>
>>
>
>We should make the docs mention it ;-)
>
>
On my list!
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: a few questions (sorry quite long)
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 02 Mar 2005, Peter Reilly <pe...@apache.org> wrote:
> The doc does not mention it, but <scriptdef> inherits attributes
> from DefBase,
We should make the docs mention it ;-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: a few questions (sorry quite long)
Posted by Peter Reilly <pe...@apache.org>.
Stefan Bodewig wrote:
>On Mon, 28 Feb 2005, James Fuller <ji...@ruminate.co.uk> wrote:
>
>
>
>>- does scriptdef have namespace capability
>>
>>
>
>I read in a comment on my blog that a user found the only way to place
>a scriptdef'ed task into a namspace other than default was putting it
>into an antlib. This feels wrong.
>
>
The doc does not mention it, but <scriptdef> inherits attributes from
DefBase,
so the following works:
<scriptdef name="a" uri="a.b.c" language="beanshell">
<attribute name="attr"/>
self.log("Attribute attr1 = " + attributes.get("attr"));
</scriptdef>
<a xmlns="a.b.c" attr="b"/>
</target>
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: a few questions (sorry quite long)
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 28 Feb 2005, James Fuller <ji...@ruminate.co.uk> wrote:
> - does scriptdef have namespace capability
I read in a comment on my blog that a user found the only way to place
a scriptdef'ed task into a namspace other than default was putting it
into an antlib. This feels wrong.
> - note: there is no 2005 copyright in ant manual/docs
We only change that on files that have actually changed.
> -main/org/apache/tools/bzip
> -main/org/apache/tools/bzip2
> -main/org/apache/tools/mail
> -main/org/apache/tools/tar
> -main/org/apache/tools/zip
> excuse my ignorance here (well if u never ask questions...)....are
> these are org.apache.tools packages used by other apache projects
No. They've been forked into Avalon Excalibur once and from there to
Jakarta Commons, but our version is tested and used the most 8-)
> perhaps we could prune
> -main.com.ice.tar
> -main.com.oreilly.servlet
Are they still there? I don't see them in my working copy.
The directories have been created by the originial sorce import. They
are org.apache.tools.tar and org.apache.tools.mail now.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: a few questions (sorry quite long)
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 01 Mar 2005, Steve Loughran <st...@apache.org> wrote:
> James Fuller wrote:
>> Steve Loughran wrote:
>>
>>> James Fuller wrote:
>>>> - couldnt find any logging/listener tests under testcases ?
>>>
>> sacre!
>
> I know. naughty. A lot of ant core lacks explicit tests,
True.
> you have to write them before you make any changes, however. The
> reason: ant core predates junit and <junit>.
I don't think there is much code left that predates <junit> and
certainly none that would predate JUnit 2.x.
>>>> - any update on webdav task
>>>
>>>
>>> We arent doing one.
>> ok, this looks like a nice first submission for me then.
>
> maybe, but the best place for it is next to the webdav
> code. Assuming that is slide, that is where it should live. Makes
> versioning easier.
AFAIK Slide already offers Ant tasks. Ant in Jakarta Commons there is
the VFS project that has Ant tasks to copy and delet on all supported
"filesystems" which includes WebDAV.
>> was wondering if there is a more appropriate apache project for
>> these org.apache.tools.* packages....
Then Ant had to depend on this other project. The main reason we have
them with Ant is that we can bootstrap Ant more easily that way.
> Well, they are all the generic tools stuff, 'utils' is the only
> other name that woudl make sense.
Not that Ant itself is in org.apache.tools.ant, not org.apache.ant.
This is also part of Ant's history, being nothing but a tool to build
Tomcat.
There is a jakarta-tools CVS module that happens to create a file
moo.jar which is used by the Jakarta Watchdog project (Tomcat's
test-suite, if you want to call it that). Not that I'd know about
that module if it wasn't for Gump.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: a few questions (sorry quite long)
Posted by Steve Loughran <st...@apache.org>.
James Fuller wrote:
> Steve Loughran wrote:
>
>> James Fuller wrote:
>>
>>> btw I have a few general developer questions... before I start caning
>>> bugzilla I think any responses would be well appreciated;
>>
>>
> really appreciate the time you have taken to answer.....even where you
> have confirmed simply lets me know if something is considered optional,
> must do, or a bit of cruft in the source.
>
>> This makes some sense, apart from the schema bit at the bottom.
>> Schema? We dont need no schema :)
>
>
> schema can be an opt in, admittedly writing a schema would give hints to
> editors out there...by using NRL (namespace routing language) we can
> allow authors to use whatever schema lang they prefer (my own choice is
> RELAXNG). Also through namespace declaration we can let authors use
> whatever markup they choose for descriptive blocks (xhtml, etc).
XSD is misguided and evil. Its type model doesnt match an object model
in any OO language, and it is a nightmare to code in. RelaxNG is an
alternative. We have <antdtd>; <antrelaxng> could dynamically do a relax
schema.
>>> - getlibraries has no task definition that I can see....correct me if
>>> I am wrong
>>
>>
>>
>> <libraries>
>
>
> yes, was looking for manual description of the task.
note the mention of that fact in the Ant1.7 todo list. I'd autogenerate
one, but a lot of the fun comes from nested stuff, and the existing
xdoclet doesnt do any coverage of nested things.
which reminds me, xdoclet-based docs need to cover datatypes and nested
elements.
>>> - couldnt find any logging/listener tests under testcases ?
>>
>>
> sacre!
>
I know. naughty. A lot of ant core lacks explicit tests, you have to
write them before you make any changes, however. The reason: ant core
predates junit and <junit>.
>
>>> - any update on webdav task
>>
>>
>> We arent doing one.
>
>
> ok, this looks like a nice first submission for me then.
>
maybe, but the best place for it is next to the webdav code. Assuming
that is slide, that is where it should live. Makes versioning easier.
>> We cant move things. If you move stuff, you have to leave a facade
>> class there. Why? Because we dont know who has subclassed or reused a
>> class. A lot of people use ant programatically as well as in the XML
>> layer, and we need to keep the effective API as stable as the XML
>> language. This is precisely why we are org.apache.tools.Ant
>
>
> agree, but there are a few techniques instead of just putting facade
> classes...I agree with the statement you make later about backwards
> compatibility...
>
>> Launcher is special; it is its own JAR file, and has to locate and
>> launch ant proper. it must be 100% self-contained.
>
>
> ok, thought this was the case.
>
>>> Why not move ?
>>> -main/org/apache/tools/bzip
>>> -main/org/apache/tools/bzip2
>>> -main/org/apache/tools/mail
>>> -main/org/apache/tools/tar
>>> -main/org/apache/tools/zip
>>> excuse my ignorance here (well if u never ask questions...)....are
>>> these are org.apache.tools packages used by other apache projects
>>
>>
>>
>> I think they did come from other projects, and are designed for reuse
>> outside ant.
>
>
> was wondering if there is a more appropriate apache project for these
> org.apache.tools.* packages....
Well, they are all the generic tools stuff, 'utils' is the only other
name that woudl make sense.
>
>>> - why are these tests at toplevel ?
>>> testcases/org/apache/tools/mail
>>> testcases/org/apache/tools/tar
>>> testcases/org/apache/tools/zip
>>
>>
>>
>> maybe because the things they test are at that level.
>
>
> hehe, this is linked to why we have such top level packages...once again
> history.
>
>>
>> yes, there is lot of historical stuff. Eventually we will be crushed
>> by the weight of backwards compatiblity.
>>
>> I have just updated the ant_task_guidelines doc in the repository,
>> please take a look at this and see if it clarifies things.
>
>
> thx for taking the time to answer such tiresome questions....
no, it is good to ask. if you dont, then you dont learn.
One thing that would be really good in the short term (1.7 release)
could be machine generated (xdoclet) docs. We need
-good coverage of nested elements, datatypes
-ability to provide as much info as the handwritten
-good generated HTML/PDF docs
-reuse of the generated XML by IDEs, if they so choose.
-reusable by third party projects. There are two projects I'm involved
in that do use the existing xdoclet stuff, but it is pretty brittle and
hard coded to ant's own project.
The other thing about doc improvements is that docs dont freeze until
the ship date...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: a few questions (sorry quite long)
Posted by James Fuller <ji...@ruminate.co.uk>.
Steve Loughran wrote:
> James Fuller wrote:
>
>> btw I have a few general developer questions... before I start caning
>> bugzilla I think any responses would be well appreciated;
>
really appreciate the time you have taken to answer.....even where you
have confirmed simply lets me know if something is considered optional,
must do, or a bit of cruft in the source.
> This makes some sense, apart from the schema bit at the bottom.
> Schema? We dont need no schema :)
schema can be an opt in, admittedly writing a schema would give hints to
editors out there...by using NRL (namespace routing language) we can
allow authors to use whatever schema lang they prefer (my own choice is
RELAXNG). Also through namespace declaration we can let authors use
whatever markup they choose for descriptive blocks (xhtml, etc).
> Actually I like the suggestion to an extent - code is often the wrong
> place to put metadata. But as most of the attributes of a task can be
> determined through introspection, i think xdoclet does have something
> to say.
> One thing we need to be able to describe is the situation when one of
> a set of attributes is needed. required being true/false is not enough.
...I think presenting a commenting style guide + task markup is
something useful...will work on something in the short term.
>> - getlibraries has no task definition that I can see....correct me if
>> I am wrong
>
>
> <libraries>
yes, was looking for manual description of the task.
>> - is there a list of @ant.task category types anywhere ?
>
> nope
usage optional then
>>
>> - is abstractaccess optional task @ant.task category the right way to
>> use this doc tag? also any list of ant.task category anywhere ?
>
> nope. remember the @ant tasks were a quick draft in 2002; we dont need
> to stick to them.
usage optional, thx for clearing up
>>
>> - couldnt find any logging/listener tests under testcases ?
>
sacre!
>> - MagicNames.java...whats the status and intended purpose ?
>
> Looks like it is intended to be a central repository of magic properties.
from this answer I will assume its status is open, and its use optional
>> - any update on webdav task
>
> We arent doing one.
ok, this looks like a nice first submission for me then.
> We cant move things. If you move stuff, you have to leave a facade
> class there. Why? Because we dont know who has subclassed or reused a
> class. A lot of people use ant programatically as well as in the XML
> layer, and we need to keep the effective API as stable as the XML
> language. This is precisely why we are org.apache.tools.Ant
agree, but there are a few techniques instead of just putting facade
classes...I agree with the statement you make later about backwards
compatibility...
> Launcher is special; it is its own JAR file, and has to locate and
> launch ant proper. it must be 100% self-contained.
ok, thought this was the case.
>> Why not move ?
>> -main/org/apache/tools/bzip
>> -main/org/apache/tools/bzip2
>> -main/org/apache/tools/mail
>> -main/org/apache/tools/tar
>> -main/org/apache/tools/zip
>> excuse my ignorance here (well if u never ask questions...)....are
>> these are org.apache.tools packages used by other apache projects
>
>
> I think they did come from other projects, and are designed for reuse
> outside ant.
was wondering if there is a more appropriate apache project for these
org.apache.tools.* packages....
>> - why are these tests at toplevel ?
>> testcases/org/apache/tools/mail
>> testcases/org/apache/tools/tar
>> testcases/org/apache/tools/zip
>
>
> maybe because the things they test are at that level.
hehe, this is linked to why we have such top level packages...once again
history.
>
> yes, there is lot of historical stuff. Eventually we will be crushed
> by the weight of backwards compatiblity.
>
> I have just updated the ant_task_guidelines doc in the repository,
> please take a look at this and see if it clarifies things.
thx for taking the time to answer such tiresome questions....
cheers, Jim Fuller
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: a few questions (sorry quite long)
Posted by Steve Loughran <st...@apache.org>.
James Fuller wrote:
> btw I have a few general developer questions... before I start caning
> bugzilla I think any responses would be well appreciated;
>
> --------------------------------
> a few comments on usage of XDoclet to autodoc manual
> --------------------------------
>
> as someone who is a complete fan of XDoclet and avid user in enterprise
> java computing...I am surprised at myself at having reservations with
> its usage in task definitions having a single source from which
> documentation is generated is a 'good thing'...esp in defining task, its
> attributes, as well as general documentation, but how to deal with other
> potential documentation requirements, e.g. if we wanted to we could also
> embed build scripts, example input/output, and schema definitions as
> well...perhaps there is some traction to be gained by having a simple
> task markup language
>
> without thinking....
>
> <?xml version="1.0" encoding="UTF-8"?>
> <task name="echo" xmlns:x="http://www.w3.org/1999/xhtml">
> <attribute name="message" required="true|false" default="">
> <desc>the message to echo.</desc>
> <required>Yes, unless data is included in a character section
> within this
> element.</required>
> </attribute>
> <attribute name="file" required="true|false" default="">the file to
> write the message to.</attribute>
> <attribute name="append" required="true|false" default="false">Append
> to an existing file?</attribute>
> <attribute name="level" required="true|false"
> values="error,warning,inf,verbose,debug"
> default="warning">Control the level at which this message is
> reported. One of "error",
> "warning", "info", "verbose", "debug" </attribute>
> <block name="description">
> <x:p>Echoes a message to the current loggers and listeners which
> means System.out unless
> overridden. A level can be specified, which controls at what
> logging level the message
> is filtered at.</x:p>
> <x:p>The task can also echo to a file, in which case the option
> to append rather than
> overwrite the file is available, and the level option is
> ignored</x:p>
> </block>
> <usecase>
> <!-- could place example build scripts, along with
> inputs/outputs/expected -->
> </usecase>
> <dependencies>
> <!-- if we were smart we would have this in a <getlibraries/>
> friendly format -->
> </dependencies>
> <schema type="relaxng|dtd|xmlschema" href=""/>
> </task>
This makes some sense, apart from the schema bit at the bottom. Schema?
We dont need no schema :)
>
> we could use xinclude if we wanted to break things up....also we could
> assume that code takes precedent either overwriting, or where no source
> comments exist taken from this document for ant manual definition
> purposes...I really think given task writers the ability to combine the
> power XDoclet and and external task markup format.
>
> Also this format could be impregnated with dublincore for versioning; in
> addition we could choose xhtml as an additional format...in any event
> the more meta data the better.
RDF? RDF and Schema ?:)
Actually I like the suggestion to an extent - code is often the wrong
place to put metadata. But as most of the attributes of a task can be
determined through introspection, i think xdoclet does have something to
say.
One thing we need to be able to describe is the situation when one of a
set of attributes is needed. required being true/false is not enough.
>
>
> -----------------------------------------
> a few general comments
> ----------------------------------------
>
> - getlibraries has no task definition that I can see....correct me if I
> am wrong
<libraries>
> - does scriptdef have namespace capability
>
> - i think its important to make sure developers for for
> DispatchTask...its seems to be buried
hadnt seen it myself
>
> - note: there is no 2005 copyright in ant manual/docs
should appear in edited files
> - is there a list of @ant.task category types anywhere ?
nope
>
> - is abstractaccess optional task @ant.task category the right way to
> use this doc tag? also any list of ant.task category anywhere ?
nope. remember the @ant tasks were a quick draft in 2002; we dont need
to stick to them.
>
> - couldnt find any logging/listener tests under testcases ?
probably arent any then :(
>
> - MagicNames.java...whats the status and intended purpose ?
>
Looks like it is intended to be a central repository of magic properties.
> - any update on webdav task
We arent doing one.
>
> --------------------------------------------
> some very boring and picky refactoring related thoughts
> --------------------------------------------
>
> I see a lot of Ant refactoring opportunities with respect to package
> naming...no doubt the twin poles of maintaining backwards compatibility
> with cutting edge functionality has caused a bit of chaos in the source
> tree.
>
> There are a few methods of mapping old package names (satisfy
> deprecated, older calls) to better logical structures...any thoughts re
> this ?
>
We cant move things. If you move stuff, you have to leave a facade class
there. Why? Because we dont know who has subclassed or reused a class. A
lot of people use ant programatically as well as in the XML layer, and
we need to keep the effective API as stable as the XML language. This
is precisely why we are org.apache.tools.Ant
> if so....then a few suggestions on moving things around;
>
> Why not move things like
> -org/apache/tools/launch/Locator to
> -org/apache/tools/helper
Launcher is special; it is its own JAR file, and has to locate and
launch ant proper. it must be 100% self-contained.
>
>
> Why not move
> -org/apache/tools/NoBannerLogger, SubBuildListener, XMLLogger to
> -org/apache/tools/listener
>
>
> Why not move ?
> -main/org/apache/tools/bzip
> -main/org/apache/tools/bzip2
> -main/org/apache/tools/mail
> -main/org/apache/tools/tar
> -main/org/apache/tools/zip
> excuse my ignorance here (well if u never ask questions...)....are these
> are org.apache.tools packages used by other apache projects
I think they did come from other projects, and are designed for reuse
outside ant.
>
>
> Also in testcases things are a bit messy...for example why not put dummy
> into
> -testcases/org/apache/tools/dummy
>
>
> along these lines, I find burying property files can sometimes be
> detrimental, for example in main source we have;
> -main/org/apache/tools/taskdef/defaults.properties
> -main/org/apache/tools/types/defaults.properties
> -main/org/apache/tools/listener/defaults.properties
> is heritical to move these to somewhere more visible ?
No, except we know that they are there. One for types, one for tasks,
one for listeners.
>
> -also quite a bit of property files scattered about testcases...might be
> useful to agree on some formalism here
>
> perhaps we could prune
> -main.com.ice.tar
> -main.com.oreilly.servlet
>
>
> - why are these tests at toplevel ?
> testcases/org/apache/tools/mail
> testcases/org/apache/tools/tar
> testcases/org/apache/tools/zip
maybe because the things they test are at that level.
>
> - dont understand why dispatch has its own directory ?
>
> many thx, and many apologies for my naive questions.....I know that (esp
> refactorings) there will be backward compatibility issues dominating the
> reasons why things exist.
yes, there is lot of historical stuff. Eventually we will be crushed by
the weight of backwards compatiblity.
I have just updated the ant_task_guidelines doc in the repository,
please take a look at this and see if it clarifies things.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org