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>