You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Martin van den Bemt <ml...@mvdb.net> on 2002/06/10 02:05:05 UTC

[PATCH] BETWIXT A lot of fixes...

Hi everyone,

Fixed/Changed the following things :

- Indention
The indention didn't work the way it supposed to. If you set the
indention level to eg 2 spaces, it would add 4 spaces.
Since the defaultbehaviour of prettyPrint() was 4 spaces, I made sure
that it still works that way.
If I know call setIndent("  "); it will actually use 2 spaces..
- wrapCollectionsInElement
This wasn't implemented at all. The default behaviour was to wrap them
in collections and I kept it that way (even though the default was not
to). It now correctly parses xml files in the format (when setting this
option to false):
<element>
  <subelement/>
  <subelement/>
</element>
The default behaviour of this will be :
<element>
  <subelements>
    <subelement/>
    <subelement/>
  </subelements>
<element>
I needed to add an extra getter/setter to the ElementDescriptor to get
this done correctly and without changing to much code.
- setNameMapper
Deprecated this in favour if setElementNameMapper and
setAttributeNameMapper. If you just set setElementNameMapper, the
setAttributeNameMapper will use the same NameMapper that is used in
setElemementNameMapper. This is the way it worked, and we need to keep
backward compatible. The original nameMapper works as the
ElementNameMapper.

- DefaultPluralStemmer
Was a bit freely implemented when multiple matches were found.
Say the property to get was "y" and the valaues in the map are "y",
"yes", "yesno", it could return eg yesno, when you actually want y.
I added a "best match" policy, which will always return the equals, when
it is found or the closest match. (the match with the minimum length).
Don't know if in real life this can actually happen, but in the testcase
it can ;). It does a log.warn to actually say that we are using a
certain match.

Tests :

- The tests currently in cvs are all passing, without change.
- Tested maven from cvs with the new jar and it works (I will also
supply a patch for maven when this is committed).
- Didn't test the current scarab (John, just your NameMapper call is
giving a deprecated message on compile)
- Adjusted the maven testcase in betwixt to use the ElementNameMapper.
- Added testcases for the strategy package, so we can insure the current
behaviour will stay the same and if not, we actually get a failing
testcase.
- Added testcase for my specific xml file, which started all this
programming in the first place. I added a new test package called
org.apache.commons.betwixt.schema. The testcase is pretty well
documented and can be used nicely as example code.

unknowns :

- The .betwixt files. I didn't dig into that, and didn't check if my
changes break anything, if it isn't covered by tests, that is..
- The decapitalizeNameMapper changes FooBar to fooBar. Decapitalization
(at least the way I use/know the word), should return foobar. Let me
know if it needs "fixing".

Still broken :

The demo.<whatever> targets are broken (has nothing to do with my
patches btw). The error is : maven.dependency.classpath not found.. 

Have fun ;)

Mvgr,
Martin

Re: [PATCH] BETWIXT A lot of fixes...

Posted by Martin van den Bemt <ml...@mvdb.net>.
Hmm... let's clear the confusion ;)

On Tue, 2002-06-11 at 23:58, robert burrell donkin wrote:
> 
> On Tuesday, June 11, 2002, at 10:41 PM, Martin van den Bemt wrote:
> 
> > Ho Robert,
I meant hi ;)
> >
> >
> > Do we have a todo list somewhere before we can release ?
> 
> i was a bit confused by what you meant by the to do list in your last 
> email.
> 
> there is a to do list which is generated by maven. is this what you meant?

Initially yes.. I thought I am into betwixt right now, so why not help
out more. 

> 
> the two main items on this are a DOM walker and a SAW writer both of which 
> are fairly major tasks. i was hoping to dissuade you from taking on either 
> of these just yet.

Understood that ;)

> 
> the other item is the documentation task which i transfered from the 
> package documentation.
> 
> > I won't mind making testcases (did a few already), but one thing I don't
> > get at all is the .betwixt files (they just don't like me or something).
> > When looking at the documentation it screams for more explenation (don't
> > know how well the files are covered by tests btw).
> 
> the documentation does need improving. that's where i'm going to be 
> concentrating my effects. 

Cool.. documentation is not my best quality (see below ;). 

> (or am i getting confused again - are you 
> referring to the documentation for the test cases?)

Documentation in general, but normally I use my testcases as
documentation (to make it more confusing). 
To document in testcases, I get structure in an otherwise unstructured
blur of words, which just confuses the hell out of people ;)
In my testcases I describe the intended behaviour in the javadoc or
inline and how the intended behaviour is achieved. If the test fails,
something is wrong in my perception of what is intended or there is a
"bug" ;).
This way I also am exploring how stuff works.

> 
> > If you have any specific wishes for tests, let me know.. (especially
> > when it makes the release date closer).
> 
> most of the test cases are not really of good quality. they should 
> probably be rewritten to use xml-unit or something. on reflection i don't 
> think that there's time for much improvement before the release.

I'll look at the tests  for improvements tommorow night (it's geting
late now;)). If I see a "should do this and this", (in eg
TestMavenProject.java), then I will try to make it work.
I prefer removing however the dependency of the maven test , since that
test depends on an external jar.  
The missing roundTrip tests are already covered in my schema tests, so
we can probably do with that one.
I will run nounit over betwixt to see what stuff is not covered anywhere
and try to fix it.. 

Mvgr,
Martin




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] BETWIXT A lot of fixes...

Posted by robert burrell donkin <ro...@mac.com>.
On Tuesday, June 11, 2002, at 10:41 PM, Martin van den Bemt wrote:

> Ho Robert,
>
>
> Do we have a todo list somewhere before we can release ?

i was a bit confused by what you meant by the to do list in your last 
email.

there is a to do list which is generated by maven. is this what you meant?

the two main items on this are a DOM walker and a SAW writer both of which 
are fairly major tasks. i was hoping to dissuade you from taking on either 
of these just yet.

the other item is the documentation task which i transfered from the 
package documentation.

> I won't mind making testcases (did a few already), but one thing I don't
> get at all is the .betwixt files (they just don't like me or something).
> When looking at the documentation it screams for more explenation (don't
> know how well the files are covered by tests btw).

the documentation does need improving. that's where i'm going to be 
concentrating my effects. (or am i getting confused again - are you 
referring to the documentation for the test cases?)

> If you have any specific wishes for tests, let me know.. (especially
> when it makes the release date closer).

most of the test cases are not really of good quality. they should 
probably be rewritten to use xml-unit or something. on reflection i don't 
think that there's time for much improvement before the release.

- robert


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] BETWIXT A lot of fixes...

Posted by Martin van den Bemt <ml...@mvdb.net>.
Ho Robert,


Do we have a todo list somewhere before we can release ? 
I won't mind making testcases (did a few already), but one thing I don't
get at all is the .betwixt files (they just don't like me or something).
When looking at the documentation it screams for more explenation (don't
know how well the files are covered by tests btw).
If you have any specific wishes for tests, let me know.. (especially
when it makes the release date closer).

Mvgr,
Martin

 

On Tue, 2002-06-11 at 23:38, robert burrell donkin wrote:
> 
> On Tuesday, June 11, 2002, at 08:32 PM, Martin van den Bemt wrote:
> 
> > Your welcome ;)
> > I will start with the todo list, if someone else hasn't started that
> > already..
> 
> if you mean that you're going to start looking at the tasks on the to do 
> (rather than enhancing the to do list documentation) then i'm going to 
> take a look at the SAXWriter once this release has happened.
> 
> personally, i'd rather see our immediate effects focus on documentation 
> and creation of improved test cases so that we can push towards an early 
> release.
> 
> - robert
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] BETWIXT A lot of fixes...

Posted by robert burrell donkin <ro...@mac.com>.
On Tuesday, June 11, 2002, at 08:32 PM, Martin van den Bemt wrote:

> Your welcome ;)
> I will start with the todo list, if someone else hasn't started that
> already..

if you mean that you're going to start looking at the tasks on the to do 
(rather than enhancing the to do list documentation) then i'm going to 
take a look at the SAXWriter once this release has happened.

personally, i'd rather see our immediate effects focus on documentation 
and creation of improved test cases so that we can push towards an early 
release.

- robert


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] BETWIXT A lot of fixes...

Posted by Martin van den Bemt <ml...@mvdb.net>.
Your welcome ;)
I will start with the todo list, if someone else hasn't started that
already..

Mvgr,
Martin

On Tue, 2002-06-11 at 18:10, James Strachan wrote:
> Hi Martin
> 
> I've implemented your numerous patches - many thanks!
> 
> The only minor change I made was to use 2 spaces as the default pretty-print
> indentation, which was what it was meant to be all along (though thanks to
> your patches it now actually works!).
> 
> I've updated the website to reflect these changes. Keep up the great work
> Martin!
> 
> James
> ----- Original Message -----
> From: "Martin van den Bemt" <ml...@mvdb.net>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Monday, June 10, 2002 1:05 AM
> Subject: [PATCH] BETWIXT A lot of fixes...
> 
> 
> > Hi everyone,
> >
> > Fixed/Changed the following things :
> >
> > - Indention
> > The indention didn't work the way it supposed to. If you set the
> > indention level to eg 2 spaces, it would add 4 spaces.
> > Since the defaultbehaviour of prettyPrint() was 4 spaces, I made sure
> > that it still works that way.
> > If I know call setIndent("  "); it will actually use 2 spaces..
> > - wrapCollectionsInElement
> > This wasn't implemented at all. The default behaviour was to wrap them
> > in collections and I kept it that way (even though the default was not
> > to). It now correctly parses xml files in the format (when setting this
> > option to false):
> > <element>
> >   <subelement/>
> >   <subelement/>
> > </element>
> > The default behaviour of this will be :
> > <element>
> >   <subelements>
> >     <subelement/>
> >     <subelement/>
> >   </subelements>
> > <element>
> > I needed to add an extra getter/setter to the ElementDescriptor to get
> > this done correctly and without changing to much code.
> > - setNameMapper
> > Deprecated this in favour if setElementNameMapper and
> > setAttributeNameMapper. If you just set setElementNameMapper, the
> > setAttributeNameMapper will use the same NameMapper that is used in
> > setElemementNameMapper. This is the way it worked, and we need to keep
> > backward compatible. The original nameMapper works as the
> > ElementNameMapper.
> >
> > - DefaultPluralStemmer
> > Was a bit freely implemented when multiple matches were found.
> > Say the property to get was "y" and the valaues in the map are "y",
> > "yes", "yesno", it could return eg yesno, when you actually want y.
> > I added a "best match" policy, which will always return the equals, when
> > it is found or the closest match. (the match with the minimum length).
> > Don't know if in real life this can actually happen, but in the testcase
> > it can ;). It does a log.warn to actually say that we are using a
> > certain match.
> >
> > Tests :
> >
> > - The tests currently in cvs are all passing, without change.
> > - Tested maven from cvs with the new jar and it works (I will also
> > supply a patch for maven when this is committed).
> > - Didn't test the current scarab (John, just your NameMapper call is
> > giving a deprecated message on compile)
> > - Adjusted the maven testcase in betwixt to use the ElementNameMapper.
> > - Added testcases for the strategy package, so we can insure the current
> > behaviour will stay the same and if not, we actually get a failing
> > testcase.
> > - Added testcase for my specific xml file, which started all this
> > programming in the first place. I added a new test package called
> > org.apache.commons.betwixt.schema. The testcase is pretty well
> > documented and can be used nicely as example code.
> >
> > unknowns :
> >
> > - The .betwixt files. I didn't dig into that, and didn't check if my
> > changes break anything, if it isn't covered by tests, that is..
> > - The decapitalizeNameMapper changes FooBar to fooBar. Decapitalization
> > (at least the way I use/know the word), should return foobar. Let me
> > know if it needs "fixing".
> >
> > Still broken :
> >
> > The demo.<whatever> targets are broken (has nothing to do with my
> > patches btw). The error is : maven.dependency.classpath not found..
> >
> > Have fun ;)
> >
> > Mvgr,
> > Martin
> >
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> 
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] BETWIXT A lot of fixes...

Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Martin

I've implemented your numerous patches - many thanks!

The only minor change I made was to use 2 spaces as the default pretty-print
indentation, which was what it was meant to be all along (though thanks to
your patches it now actually works!).

I've updated the website to reflect these changes. Keep up the great work
Martin!

James
----- Original Message -----
From: "Martin van den Bemt" <ml...@mvdb.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, June 10, 2002 1:05 AM
Subject: [PATCH] BETWIXT A lot of fixes...


> Hi everyone,
>
> Fixed/Changed the following things :
>
> - Indention
> The indention didn't work the way it supposed to. If you set the
> indention level to eg 2 spaces, it would add 4 spaces.
> Since the defaultbehaviour of prettyPrint() was 4 spaces, I made sure
> that it still works that way.
> If I know call setIndent("  "); it will actually use 2 spaces..
> - wrapCollectionsInElement
> This wasn't implemented at all. The default behaviour was to wrap them
> in collections and I kept it that way (even though the default was not
> to). It now correctly parses xml files in the format (when setting this
> option to false):
> <element>
>   <subelement/>
>   <subelement/>
> </element>
> The default behaviour of this will be :
> <element>
>   <subelements>
>     <subelement/>
>     <subelement/>
>   </subelements>
> <element>
> I needed to add an extra getter/setter to the ElementDescriptor to get
> this done correctly and without changing to much code.
> - setNameMapper
> Deprecated this in favour if setElementNameMapper and
> setAttributeNameMapper. If you just set setElementNameMapper, the
> setAttributeNameMapper will use the same NameMapper that is used in
> setElemementNameMapper. This is the way it worked, and we need to keep
> backward compatible. The original nameMapper works as the
> ElementNameMapper.
>
> - DefaultPluralStemmer
> Was a bit freely implemented when multiple matches were found.
> Say the property to get was "y" and the valaues in the map are "y",
> "yes", "yesno", it could return eg yesno, when you actually want y.
> I added a "best match" policy, which will always return the equals, when
> it is found or the closest match. (the match with the minimum length).
> Don't know if in real life this can actually happen, but in the testcase
> it can ;). It does a log.warn to actually say that we are using a
> certain match.
>
> Tests :
>
> - The tests currently in cvs are all passing, without change.
> - Tested maven from cvs with the new jar and it works (I will also
> supply a patch for maven when this is committed).
> - Didn't test the current scarab (John, just your NameMapper call is
> giving a deprecated message on compile)
> - Adjusted the maven testcase in betwixt to use the ElementNameMapper.
> - Added testcases for the strategy package, so we can insure the current
> behaviour will stay the same and if not, we actually get a failing
> testcase.
> - Added testcase for my specific xml file, which started all this
> programming in the first place. I added a new test package called
> org.apache.commons.betwixt.schema. The testcase is pretty well
> documented and can be used nicely as example code.
>
> unknowns :
>
> - The .betwixt files. I didn't dig into that, and didn't check if my
> changes break anything, if it isn't covered by tests, that is..
> - The decapitalizeNameMapper changes FooBar to fooBar. Decapitalization
> (at least the way I use/know the word), should return foobar. Let me
> know if it needs "fixing".
>
> Still broken :
>
> The demo.<whatever> targets are broken (has nothing to do with my
> patches btw). The error is : maven.dependency.classpath not found..
>
> Have fun ;)
>
> Mvgr,
> Martin
>


----------------------------------------------------------------------------
----


> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [PATCH] BETWIXT A lot of fixes...

Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Martin van den Bemt" <ml...@mvdb.net>
> Still broken :
>
> The demo.<whatever> targets are broken (has nothing to do with my
> patches btw). The error is : maven.dependency.classpath not found..

Though if you use the last release of Maven (b4) it should work fine. At
least it does for me ;-)

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>