You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Ingmar J Stein <st...@xtramind.com> on 2002/05/07 09:14:52 UTC
echoproperties
> Shouldn't we change the subject of this thread?
done :-)
> I looked over the code this weekend. Overall, looks good. As for the new
> formatting, I was imagining something more generic, similar to how the
JUnit
> task handles the Formatter: move the actual output code into its own class
> (which may be reused easily by other tasks), have two defaults ("xml" and
> "text"), and allow for the user to specify their own class if they want
> something else. Of course, that may be overkill for this small task :-)
Yes, this is what I meant when I was talking about a common interface
that both property writers implement. If noone comes up with another
property file format, then I think we should stick to the current solution.
Factoring out the i/o functions does not give us any additional benefit
right
now and as you said it, it's overkill for this small task.
> The "srcfile" is an interesting addition. I like it. Will there be a
> future need/want to load the XML formatted properties here?
I don't see that need right now, but it might be a good idea to
merge xmlproperties and echoproperties. I can imagine a single
task that reads and writes property files in either text or XML format.
> Here are the things that stood out: the property file reading doesn't
check
> the "failonerror" flag
Right. I will fix that.
> no document updates :)
Dammit, you noticed that :-)
> the loading of the
> Properties object from the project Hashtable relies on a JDK 1.2 API
> (putAll).
Yeah, that's why it's an optional task, isn't it?
> I like your tests. I couldn't figure a good way to check the XML
> generation, but your "indexOf" is good. My only suggestion is to create
the
> echoproperties.properties in the "setup" target through the <echo
> file="echoproperties.properties"> task, and delete it in the "cleanup"
> target. Yours isn't wrong, but this just eliminates one more external
file
> dependency in the tests.
Mmh, that's a matter of taste. Personally, I don't like to regenerate static
files every time I run a test, but if that's ant's test writing policy, I
will change
it at once.
> I've included my document changes. Due the to the HTML stripping, I've
> zipped it up. Unfortunately, from work my CVS access is blocked by the
> firewall, so I couldn't get a proper diff. Is there an xdocs version I
> should be modding for v1.6 instead?
Hmm, anyone?
Ingmar
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: echoproperties
Posted by Ingmar J Stein <st...@xtramind.com>.
> > Here are the things that stood out: the property file reading doesn't
> check
> > the "failonerror" flag
>
> Right. I will fix that.
Done. I also added some more error checking for srcfile and destfile
and a new test that checks if failonerror works when reading a property
file.
After your review, I consider the task commitable...
Ingmar
Re: echoproperties
Posted by Diane Holt <ho...@yahoo.com>.
--- Ingmar J Stein <st...@xtramind.com> wrote:
> I can imagine a single task that reads and writes property files in
> either text or XML format.
Would it make sense to just enhance <propertyfile> to allow formatting?
Diane
=====
(holtdl@yahoo.com)
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>