You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by joe kim <jo...@gmail.com> on 2006/06/30 23:41:55 UTC
Atom Data Model and Testing
Hey Guys,
I've been spending some time getting situated with Abdera. I have a
two thoughts that I would be willing to drive implementation on. I am
still getting started, so feel free to provide feedback or redirect
me. I am still an atom novice compared to you guys.
In general, I feel like Abdera could be simplified. Java frameworks
are becoming extreme in terms of providing levels of indirection. You
guys may have seen this call stack:
http://ptrthomas.wordpress.com/2006/06/06/java-call-stack-from-http-upto-jdbc-as-a-picture/
1. Build a pojo module free of any dependencies to represent the Atom
data model
Pojo's have a programming model with a very low cost to entry. If the
data model was implemented as pojo's then there would be much less
added programming model complexity for tasks that focus in on data
manipulation.
For example take a look at how an object is created.
To create a feed you do:
Feed feed = Factory.INSTANCE.newFeed();
In the Factory class, INSTANCE is defined as:
public static final Factory INSTANCE = ServiceUtil.newFactoryInstance();
ServiceUtil creates the factory with:
public static Factory newFactoryInstance() {
return (Factory) newInstance(
CONFIG_FACTORY,
ConfigProperties.getDefaultFactory());
}
ConfigProperties will then try to read from a configuration file or
return a default value. But, apparently to use a different factory
you have to modify a file. Wouldn't it be much nicer if you could just
do this:
Feed f = new Feed();
The difference between the two ways of instantiating an Object becomes
more apparent to the developer when he/she needs to make some changes.
Let's look at extensions. From the javadoc:
* There are four ways of supporting extension elements.
*
* 1. Implement your own Factory (hard)
* 2. Subclass the default Axiom-based Factory (also somewhat difficult)
* 3. Implement and register an ExtensionFactory (wonderfully simple)
* 4. Use the Feed Object Model's dynamic support for extensions (also
very simple)
Being mentally challenged as I am, I do not really understand what
that means. My conclusion is that I would have to do some extra
reading to understand the options and that translates to overhead with
regard to my extension. If all I wanted to do was add an extra field,
Java's core object oriented syntax suits me just fine.
class PersonalFeed extends Feed {
private boolean markedAsRead = false;
public boolean isMarkedAsRead(){ return markedAsRead ; }
public void setMarkedAsRead(boolean m){ markedAsRead = m };
}
I would really like to see a pojo module that represents the Atom model.
2. Use TestNG as a testing framework.
I did some research on Java testing frameworks and it looks like
TestNG is the most capable of JUnit 3.8, JUnit 4, and TestNG. It will
allow us to continue using JUnit 3.8 test cases and provides a much
more flexible test configuration. I think org.apache.examples.simple
would be a good starting place for creating test cases.
Any thoughts?
Cheers,
Joe
Re: Atom Data Model and Testing
Posted by joe kim <jo...@gmail.com>.
Nice! I look forward to playing with the JSON and RDF stuff.
> Hi Joe,
>
> I have a JSON serialization that will be checked in soon against the new
> writer/reader changes James made especially for this and an RDF
> parser/reader that we have as well.
>
> -Elias
>
Re: Atom Data Model and Testing
Posted by Elias Torres <el...@torrez.us>.
joe kim wrote:
> James,
>
> Thanks for taking the time to explain your stance on these things. I
> like your experimentation approach. I will play around with some
> things and get back to you on that in a week or so.
>
>> Rob Yates (who is on paternity leave right now so likely can't respond
>> right now) has performed some performance analysis of Abdera with Axiom
>> relative to Rome (which separates the model impl from the parsing).
>> Parsing just titles and links from Tim Bray's feed, Rome used 6+MB of
>> RAM and over 600 million CPU instructions; Abdera with Axiom used around
>> 700k of RAM and around 90 million CPU instructions. The secret of the
>> performance improvement was in the use of Axiom and StAX -- that is, to
>> say, pull parsing and lazy creation of the object model.
>
> These performance metrics are most likely a result of JDOM vs.
> Axiom/StAX and not due to the model being separated from the parsing.
> Do you happen to know what tool Rob used to determine CPU
> instructions? I would imagine it would vary due to the nature of JIT.
>
>> I had originally started down the path you are suggesting, this is
>> better. Please, run some performance analysis of your own. Look at the
>> stack traces. Compare them with those of Rome. I think you'll be
>> surprised at how much kruft is *not* there *because* of the direct
>> dependencies on Axiom and StAX.
>
> I think API cleanliness is orthogonal to performance. Here are my
> questions:
> 1) Is the API uglier or simpler because of dependencies on Axiom and StAX?
> 2) Is the API higher performance due to dependencies on Axiom and StAX?
>
> I am arguing that 1) is uglier. Not going to argue 2. unless I run my
> own performance tests like you suggested.
>
> One last question, JSON support. Have you and smackman made any
> progress on JSON serialization?
>
> http://smackman.com/2006/05/08/applicationatomjson/
>
> How would suggest atom+json serialization be implemented?
>
> Joe
>
Hi Joe,
I have a JSON serialization that will be checked in soon against the new
writer/reader changes James made especially for this and an RDF
parser/reader that we have as well.
-Elias
Re: Atom Data Model and Testing
Posted by Robert Yates <ro...@gmail.com>.
joe kim wrote:
> These performance metrics are most likely a result of JDOM vs.
> Axiom/StAX and not due to the model being separated from the parsing.
> Do you happen to know what tool Rob used to determine CPU
> instructions? I would imagine it would vary due to the nature of JIT.
I used an internal tool that we call "Arcflow". I believe some
variation of it may be in the rational software portfolio but I am not
sure. For performing the measurements we actually turn the JIT off,
otherwise the results get diluted by compile steps, and while I agree
that this may scew the results a little, it provides for a very fair
comparison.
Rob
Re: Atom Data Model and Testing
Posted by James M Snell <ja...@gmail.com>.
A bit. Last week I checked in pluggable writer support. The API needs
a few tweaks here and there (mostly in the factory model) but the way it
works is rather straightforward.
OutputStream out = ...;
WriterFactory factory = WriterFactory.INSTANCE;
Writer writer = factory.newInstance("json");
writer.writeTo(feed, out);
>From there it's just a matter of writing the JSON writer implementation,
which, I believe, Elias is working on.
- James
joe kim wrote:
> [snip]
> One last question, JSON support. Have you and smackman made any
> progress on JSON serialization?
>
> http://smackman.com/2006/05/08/applicationatomjson/
>
> How would suggest atom+json serialization be implemented?
>
> Joe
>
Re: Atom Data Model and Testing
Posted by joe kim <jo...@gmail.com>.
James,
Thanks for taking the time to explain your stance on these things. I
like your experimentation approach. I will play around with some
things and get back to you on that in a week or so.
> Rob Yates (who is on paternity leave right now so likely can't respond
> right now) has performed some performance analysis of Abdera with Axiom
> relative to Rome (which separates the model impl from the parsing).
> Parsing just titles and links from Tim Bray's feed, Rome used 6+MB of
> RAM and over 600 million CPU instructions; Abdera with Axiom used around
> 700k of RAM and around 90 million CPU instructions. The secret of the
> performance improvement was in the use of Axiom and StAX -- that is, to
> say, pull parsing and lazy creation of the object model.
These performance metrics are most likely a result of JDOM vs.
Axiom/StAX and not due to the model being separated from the parsing.
Do you happen to know what tool Rob used to determine CPU
instructions? I would imagine it would vary due to the nature of JIT.
> I had originally started down the path you are suggesting, this is
> better. Please, run some performance analysis of your own. Look at the
> stack traces. Compare them with those of Rome. I think you'll be
> surprised at how much kruft is *not* there *because* of the direct
> dependencies on Axiom and StAX.
I think API cleanliness is orthogonal to performance. Here are my questions:
1) Is the API uglier or simpler because of dependencies on Axiom and StAX?
2) Is the API higher performance due to dependencies on Axiom and StAX?
I am arguing that 1) is uglier. Not going to argue 2. unless I run my
own performance tests like you suggested.
One last question, JSON support. Have you and smackman made any
progress on JSON serialization?
http://smackman.com/2006/05/08/applicationatomjson/
How would suggest atom+json serialization be implemented?
Joe
Re: Atom Data Model and Testing
Posted by James M Snell <ja...@gmail.com>.
joe kim wrote:
>> -1. The current interface+impl mechanism provides a great deal of
>> flexibility in the implementation and gives us built-in serialization to
>> and from XML using Axiom that is very high performance and efficient.
>
> What performance data are you basing this on?
>
Rob Yates (who is on paternity leave right now so likely can't respond
right now) has performed some performance analysis of Abdera with Axiom
relative to Rome (which separates the model impl from the parsing).
Parsing just titles and links from Tim Bray's feed, Rome used 6+MB of
RAM and over 600 million CPU instructions; Abdera with Axiom used around
700k of RAM and around 90 million CPU instructions. The secret of the
performance improvement was in the use of Axiom and StAX -- that is, to
say, pull parsing and lazy creation of the object model.
I had originally started down the path you are suggesting, this is
better. Please, run some performance analysis of your own. Look at the
stack traces. Compare them with those of Rome. I think you'll be
surprised at how much kruft is *not* there *because* of the direct
dependencies on Axiom and StAX.
If, after running some performance tests, you think the pojo approach
would still be easier/simpler, I would encourage you to implement it
side by side with the Axiom stuff (create a new set of impl classes for
the interfaces, including the parser, factory, xpath, etc) and do a
side-by-side comparison of the two.
>> Factory factory = new MyFactory();
>>
>> Or, you could also...
>>
>> Factory factory = new FOMFactory();
>
> I suggest that writing MyFactory will be easier if the base data model
> is implemented as pojo's.
>
Go ahead and give it a try. I think you'll find more benefit to Axiom
that you're giving it credit for.
>> The current configuration model is in place to allow for alternative
>> default implementations of the object model. For example, we currently
>> have at least one project going on internally that is working on
>> replacing the Axiom-based implementation with an SDO based
>> implementation, using the exact same set of interfaces.
>
> That sounds good. So they are using the interfaces from
> org.apache.abdera.model and are implementing their own Factory?
>
Yes.
>> We can already do this.
>>
>> class MyFeed extends FOMFeed {
>> ...
>> }
>
> FOMFeed is not general purpose enough due to it's dependence on axiom.
>
The dependency on Axiom gives us our performance advantage as well as
xml serialization for free.
>> I don't see this as buying us anything relative to what we already have
>> and would likely degrade the performance advantages of the Axiom-based
>> impl we already have in place.
>
> It buys a cleaner way to implement data model flexibility. Inheriting
> from a class is really nice because you do not have to reinvent the
> wheel, but things start getting nasty when you have to inherit kruft
> that you don't need, such as axiom code when using a different parser.
> How much do you really think this will degrade performance? My
> feeling is that it would be negligible. Sorry, but I have to quote
> Knuth, "Premature optimization is the root of all evil (or at least
> most of it) in programming."
>
What's nice about Axiom is that you can actually replace the underlying
parser. In Abdera, Axiom is not kruft, it provides the fundamental XML
infoset model and XML support.
However, like I said, the reason Feed, Entry, etc are interfaces is to
allow for alternative implementations. Someone could come along and
plug-in a non-Axiom based implementation of those interfaces and have it
just work.
>> -0.5. JUnit has much broader support and, so far, has done everything
>> we've needed it to do. Unless there is something that TestNG offers
>> that we absolutely need and cannot get with JUnit, I don't see the
>> advantage.
>
> Both JUnit 4 and TestNG provide the same capabilities as the current
> JUnit 3.8 plus some. I am not sure what the benefits of "broader
> support" are. JUnit 4 and TestNG can be called from ant and eclipse
> and probably maven. Anyhow, we can take this to a new thread.
>
> Joe
>
- James
Re: Atom Data Model and Testing
Posted by joe kim <jo...@gmail.com>.
> -1. The current interface+impl mechanism provides a great deal of
> flexibility in the implementation and gives us built-in serialization to
> and from XML using Axiom that is very high performance and efficient.
What performance data are you basing this on?
> Factory factory = new MyFactory();
>
> Or, you could also...
>
> Factory factory = new FOMFactory();
I suggest that writing MyFactory will be easier if the base data model
is implemented as pojo's.
> The current configuration model is in place to allow for alternative
> default implementations of the object model. For example, we currently
> have at least one project going on internally that is working on
> replacing the Axiom-based implementation with an SDO based
> implementation, using the exact same set of interfaces.
That sounds good. So they are using the interfaces from
org.apache.abdera.model and are implementing their own Factory?
> We can already do this.
>
> class MyFeed extends FOMFeed {
> ...
> }
FOMFeed is not general purpose enough due to it's dependence on axiom.
> I don't see this as buying us anything relative to what we already have
> and would likely degrade the performance advantages of the Axiom-based
> impl we already have in place.
It buys a cleaner way to implement data model flexibility. Inheriting
from a class is really nice because you do not have to reinvent the
wheel, but things start getting nasty when you have to inherit kruft
that you don't need, such as axiom code when using a different parser.
How much do you really think this will degrade performance? My
feeling is that it would be negligible. Sorry, but I have to quote
Knuth, "Premature optimization is the root of all evil (or at least
most of it) in programming."
> -0.5. JUnit has much broader support and, so far, has done everything
> we've needed it to do. Unless there is something that TestNG offers
> that we absolutely need and cannot get with JUnit, I don't see the
> advantage.
Both JUnit 4 and TestNG provide the same capabilities as the current
JUnit 3.8 plus some. I am not sure what the benefits of "broader
support" are. JUnit 4 and TestNG can be called from ant and eclipse
and probably maven. Anyhow, we can take this to a new thread.
Joe
Re: Atom Data Model and Testing
Posted by James M Snell <ja...@gmail.com>.
joe kim wrote:
> Hey Guys,
>
> I've been spending some time getting situated with Abdera. I have a
> two thoughts that I would be willing to drive implementation on. I am
> still getting started, so feel free to provide feedback or redirect
> me. I am still an atom novice compared to you guys.
>
> In general, I feel like Abdera could be simplified. Java frameworks
> are becoming extreme in terms of providing levels of indirection. You
> guys may have seen this call stack:
>
> http://ptrthomas.wordpress.com/2006/06/06/java-call-stack-from-http-upto-jdbc-as-a-picture/
>
>
> 1. Build a pojo module free of any dependencies to represent the Atom
> data model
>
-1. The current interface+impl mechanism provides a great deal of
flexibility in the implementation and gives us built-in serialization to
and from XML using Axiom that is very high performance and efficient.
> Pojo's have a programming model with a very low cost to entry. If the
> data model was implemented as pojo's then there would be much less
> added programming model complexity for tasks that focus in on data
> manipulation.
>
> For example take a look at how an object is created.
>
> To create a feed you do:
>
> Feed feed = Factory.INSTANCE.newFeed();
>
You can also do:
Feed feed = new FOMFeed();
> In the Factory class, INSTANCE is defined as:
>
> public static final Factory INSTANCE = ServiceUtil.newFactoryInstance();
>
> ServiceUtil creates the factory with:
>
> public static Factory newFactoryInstance() {
> return (Factory) newInstance(
> CONFIG_FACTORY,
> ConfigProperties.getDefaultFactory());
> }
>
> ConfigProperties will then try to read from a configuration file or
> return a default value. But, apparently to use a different factory
> you have to modify a file. Wouldn't it be much nicer if you could just
> do this:
>
The ConfigProperties is only used to register the default
factory/parser/etc implementation. If you want to use alternative
implementations, you could use
Factory factory = new MyFactory();
Or, you could also...
Factory factory = new FOMFactory();
The current configuration model is in place to allow for alternative
default implementations of the object model. For example, we currently
have at least one project going on internally that is working on
replacing the Axiom-based implementation with an SDO based
implementation, using the exact same set of interfaces.
> Feed f = new Feed();
>
> The difference between the two ways of instantiating an Object becomes
> more apparent to the developer when he/she needs to make some changes.
> Let's look at extensions. From the javadoc:
>
> * There are four ways of supporting extension elements.
> *
> * 1. Implement your own Factory (hard)
> * 2. Subclass the default Axiom-based Factory (also somewhat difficult)
> * 3. Implement and register an ExtensionFactory (wonderfully simple)
> * 4. Use the Feed Object Model's dynamic support for extensions (also
> very simple)
>
> Being mentally challenged as I am, I do not really understand what
> that means. My conclusion is that I would have to do some extra
> reading to understand the options and that translates to overhead with
> regard to my extension. If all I wanted to do was add an extra field,
> Java's core object oriented syntax suits me just fine.
>
> class PersonalFeed extends Feed {
> private boolean markedAsRead = false;
> public boolean isMarkedAsRead(){ return markedAsRead ; }
> public void setMarkedAsRead(boolean m){ markedAsRead = m };
> }
>
We can already do this.
class MyFeed extends FOMFeed {
...
}
> I would really like to see a pojo module that represents the Atom model.
>
I don't see this as buying us anything relative to what we already have
and would likely degrade the performance advantages of the Axiom-based
impl we already have in place.
> 2. Use TestNG as a testing framework.
>
> I did some research on Java testing frameworks and it looks like
> TestNG is the most capable of JUnit 3.8, JUnit 4, and TestNG. It will
> allow us to continue using JUnit 3.8 test cases and provides a much
> more flexible test configuration. I think org.apache.examples.simple
> would be a good starting place for creating test cases.
>
-0.5. JUnit has much broader support and, so far, has done everything
we've needed it to do. Unless there is something that TestNG offers
that we absolutely need and cannot get with JUnit, I don't see the
advantage.
> Any thoughts?
>
> Cheers,
> Joe
>
- James
Re: Atom Data Model and Testing
Posted by joe kim <jo...@gmail.com>.
Garrett,
Thanks for the reply. I will go ahead and keep testing out of this thread.
To summarize my argument, there should be a cleaner seperation between
the data model and parsing framework. The data model can be
implemented as pure, dependency-free pojos and that does not have to
come at the cost of "fancy ways to add support for new extensions".
For example, to add support for "<garretts-cool-element>With stuff in
it</garretts-cool-element>", two things would need to occur: 1) Extend
the base, data model 2) Add parsing support
With pojo's extending the base, data model is pretty easy.
For adding parsing support the developer should have options: a) Use
their own custom parsing code b) code a custom extension to a built in
abdera parser
Option b) should not be mandatory. For example, suppose I wanted to
use a jdom based parser. The current code base makes it difficult to
do that. In this scenario, I would be much happier going with option
a) and manipulating pojo's.
> > 1. Build a pojo module free of any dependencies to represent the Atom
> > data model
> >
> > Pojo's have a programming model with a very low cost to entry. If the
> > data model was implemented as pojo's then there would be much less
> > added programming model complexity for tasks that focus in on data
> > manipulation.
> >
> > For example take a look at how an object is created.
> >
> > To create a feed you do:
> >
> > Feed feed = Factory.INSTANCE.newFeed();
> >
> > In the Factory class, INSTANCE is defined as:
> >
> > public static final Factory INSTANCE = ServiceUtil.newFactoryInstance();
> >
> > ServiceUtil creates the factory with:
> >
> > public static Factory newFactoryInstance() {
> > return (Factory) newInstance(
> > CONFIG_FACTORY,
> > ConfigProperties.getDefaultFactory());
> > }
> >
> > ConfigProperties will then try to read from a configuration file or
> > return a default value. But, apparently to use a different factory
> > you have to modify a file. Wouldn't it be much nicer if you could just
> > do this:
> >
> > Feed f = new Feed();
>
> Well, keep in mind that by default you can just do
> Factory.INSTANCE.newFeed(), sure, it's a little more writing, but it's
> also part of what gives us the fancy ways to add support for new
> extensions...
>
> Also, if you want to access the objects directly, you could skip over
> the interfaces and do something like:
>
> Feed f = new FOMFeed();
FOMFeed might be a good starting point to begin pojo-izing the code.
As it is written now, if I am using a totally different XML parser,
then it does not make sense for me to have to depend on axiom because
it is integrated with the data model for the sake of "optimization".
> > The difference between the two ways of instantiating an Object becomes
> > more apparent to the developer when he/she needs to make some changes.
> > Let's look at extensions. From the javadoc:
> >
> > * There are four ways of supporting extension elements.
> > *
> > * 1. Implement your own Factory (hard)
> > * 2. Subclass the default Axiom-based Factory (also somewhat difficult)
> > * 3. Implement and register an ExtensionFactory (wonderfully simple)
> > * 4. Use the Feed Object Model's dynamic support for extensions (also
> > very simple)
> >
> > Being mentally challenged as I am, I do not really understand what
> > that means. My conclusion is that I would have to do some extra
> > reading to understand the options and that translates to overhead with
> > regard to my extension. If all I wanted to do was add an extra field,
> > Java's core object oriented syntax suits me just fine.
> >
> > class PersonalFeed extends Feed {
> > private boolean markedAsRead = false;
> > public boolean isMarkedAsRead(){ return markedAsRead ; }
> > public void setMarkedAsRead(boolean m){ markedAsRead = m };
> > }
>
> The problem is that your code doesn't actually do what that comment
> talks about. It's talking about adding support to the parser for
> parsing new and different types of content within an atom feed. For
> example, if I wanted to add support for the
> <garretts-cool-element>With stuff in it</garretts-cool-element> I
> could use the kind of extensibility it's talking about to do so. This
> is a bit more complex than a "marked as read" flag.
My code does part of what the comment is talking about. It extends
the data model. For the parsing portion, the extensibility provided
by the abdera code provides a lot of levels of indirection, but not I
do not see a compelling case supporting "flexibility". To add jdom
support it looks like I have to create a whole new Factory, deemed
"hard" by James, or I have to use FOMFeed, a class that depends on
axiom.
Cheers,
Joe
Re: Atom Data Model and Testing
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/30/06, joe kim <jo...@gmail.com> wrote:
> In general, I feel like Abdera could be simplified. Java frameworks
> are becoming extreme in terms of providing levels of indirection. You
> guys may have seen this call stack:
No argument there, simplification is great.
> 1. Build a pojo module free of any dependencies to represent the Atom
> data model
>
> Pojo's have a programming model with a very low cost to entry. If the
> data model was implemented as pojo's then there would be much less
> added programming model complexity for tasks that focus in on data
> manipulation.
>
> For example take a look at how an object is created.
>
> To create a feed you do:
>
> Feed feed = Factory.INSTANCE.newFeed();
>
> In the Factory class, INSTANCE is defined as:
>
> public static final Factory INSTANCE = ServiceUtil.newFactoryInstance();
>
> ServiceUtil creates the factory with:
>
> public static Factory newFactoryInstance() {
> return (Factory) newInstance(
> CONFIG_FACTORY,
> ConfigProperties.getDefaultFactory());
> }
>
> ConfigProperties will then try to read from a configuration file or
> return a default value. But, apparently to use a different factory
> you have to modify a file. Wouldn't it be much nicer if you could just
> do this:
>
> Feed f = new Feed();
Well, keep in mind that by default you can just do
Factory.INSTANCE.newFeed(), sure, it's a little more writing, but it's
also part of what gives us the fancy ways to add support for new
extensions...
Also, if you want to access the objects directly, you could skip over
the interfaces and do something like:
Feed f = new FOMFeed();
> The difference between the two ways of instantiating an Object becomes
> more apparent to the developer when he/she needs to make some changes.
> Let's look at extensions. From the javadoc:
>
> * There are four ways of supporting extension elements.
> *
> * 1. Implement your own Factory (hard)
> * 2. Subclass the default Axiom-based Factory (also somewhat difficult)
> * 3. Implement and register an ExtensionFactory (wonderfully simple)
> * 4. Use the Feed Object Model's dynamic support for extensions (also
> very simple)
>
> Being mentally challenged as I am, I do not really understand what
> that means. My conclusion is that I would have to do some extra
> reading to understand the options and that translates to overhead with
> regard to my extension. If all I wanted to do was add an extra field,
> Java's core object oriented syntax suits me just fine.
>
> class PersonalFeed extends Feed {
> private boolean markedAsRead = false;
> public boolean isMarkedAsRead(){ return markedAsRead ; }
> public void setMarkedAsRead(boolean m){ markedAsRead = m };
> }
The problem is that your code doesn't actually do what that comment
talks about. It's talking about adding support to the parser for
parsing new and different types of content within an atom feed. For
example, if I wanted to add support for the
<garretts-cool-element>With stuff in it</garretts-cool-element> I
could use the kind of extensibility it's talking about to do so. This
is a bit more complex than a "marked as read" flag.
> I would really like to see a pojo module that represents the Atom model.
>
> 2. Use TestNG as a testing framework.
>
> I did some research on Java testing frameworks and it looks like
> TestNG is the most capable of JUnit 3.8, JUnit 4, and TestNG. It will
> allow us to continue using JUnit 3.8 test cases and provides a much
> more flexible test configuration. I think org.apache.examples.simple
> would be a good starting place for creating test cases.
The choice of test framework seems like a totally different discussion
than the beginning of your email. Perhaps you should break it out
into a separate mail. Personally though, I would want to see some
concrete examples of why a different framework would be better than
what we've got now. JUnit is well known, and has support from many
other tools.
-garrett