RE: xmlproperties (was: JUnit writes properties for each testcase )

["Albrecht, Matt" <ma...@zilliant.com>]

Darn.  You beat me to it.  However, thanks for the submit!  Especially for
the tests.  Always nice to see more tests.  Shouldn't we change the subject
of this thread?

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 :-)

The "srcfile" is an interesting addition.  I like it.  Will there be a
future need/want to load the XML formatted properties here?

Here are the things that stood out: the property file reading doesn't check
the "failonerror" flag, no document updates :), the loading of the
Properties object from the project Hashtable relies on a JDK 1.2 API
(putAll).

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.

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?

If you want, or if anyone cares, I can submit my weekend work on putting the
formatting into their own classes.


-Matt
Try something new. 

> -----Original Message-----
> From: Ingmar J Stein [mailto:stein@xtramind.com]
> Sent: Monday, May 06, 2002 8:58 AM
> To: Ant Developers List
> Subject: Re: xmlproperties (was: JUnit writes properties for each
> testcase )
> 
> 
> > > > Matt, would you please look at the code as it is 
> completely untested
> :-)
> > > > (At least, it compiles)
> > >
> > > there is an EchoPropertiesTest.java in the tests subtree, that you
> should
> > be
> > > extending too. ..
> 
> Done. Could someone please review that?
> 
> Ingmar
> 

Re: echoproperties

[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

[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>

echoproperties

[Ingmar J Stein <st...@xtramind.com>]

> 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>