dbunit-developer

Re: [dbunit-developer] CodeHaus?

[John H. <joh...@gm...>]

Andres,

Wow, I had not considered doing datasets/tables that way with the builder
pattern. It's embarrassing that I hadn't considered this before; I got too
stuck in my own way of seeing things.

Regarding SwingBuilder, I am becoming fairly well acquainted with
FactoryBuilderSupport as I've been creating a PDF builder over iText using
it: http://github.com/johnbhurst/pdf-builder (or neat example:
http://github.com/johnbhurst/pdf-builder/blob/master/examples/questions/separators/PascalsTriangle.groovy).
FactoryBuilderSupport surely does enable a remarkably powerful yet simple
approach to builders. I'm really impressed with what can be done with it.

Regards

JH

On Wed, Sep 1, 2010 at 8:38 AM, Andres Almiray <aal...@ya...> wrote:

> Thanks John, just doing my part :-)
>
> AFAIK submitting a project to The Codehaus is fairly easy, you just need to
> fill in an application. I'm sure that a well known project such as DbUnit
> will have no problem getting into the 'haus should the team decides to take
> this option, younger or starting projects can have a hard time.
>
> Regarding fluent interfaces and their possible mix with Java, then Groovy.
> Your example looks great, here's another option following the builder
> pattern:
>
> dataset()
>     .table("owners")
>         .col("id", "first_name", "last_name", "address", "city",
> "telephone")
>         .row("1", "Mandy", "Smith"      , "12 Oxford Street", "Southfield",
> "555-1234567")
>         .row("2", "Joe"  , "Jeffries"   , "25 Baywater Lane", "Northbrook",
> "555-2345678")
>         .row("3", "Herb" , "Dalton"     , "2 Main St"       , "Southfield",
> "555-3456789")
>         .row("4", "Dave" , "Smith-Jones", "12 Kent Way"     , "Southfield",
> "555-4567890")
>     .table("pets")
>         .col("id")
>     .table("visits")
>         .col("id")
>      .build()
>
> This one assumes an internal state machine is in place so that you can't
> call col().row().col()
> Examples of such implementations can be found in Trident's
> InterpolatedPropertyBuilder and in FEST's APIs (100% Java code both).
> What we do in Groovy otoh is write a POJO for each node, then let the
> builder manage their relationships (essentially becoming the state machine).
> Coding to POJOs makes the work really easy, that's how Groovy's SwingBuilder
> came to be so flexible.
>
> Cheers,
> Andres
>
> -------------------------------------------
> http://jroller.com/aalmiray
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
>
> ------------------------------
> *From:* John Hurst <joh...@gm...>
> *To:* dbu...@li...
> *Sent:* Tue, August 31, 2010 10:14:04 PM
> *Subject:* [dbunit-developer] CodeHaus?
>
> Andres,
>
> Nice to see you following this list! You rock!
>
> What is involved in getting a project accepted into CodeHaus?
>
> With regard to Groovy, I am on the lookout for ways to make DbUnit more
> seamless with Groovy.
>
> Regards
>
> John Hurst
>
> --
> Life is interfering with my game
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>


-- 
Life is interfering with my game

Re: [dbunit-developer] CodeHaus?

[Andres A. <aal...@ya...>]

Thanks John, just doing my part :-)

AFAIK submitting a project to The Codehaus is fairly easy, you just need to fill 
in an application. I'm sure that a well known project such as DbUnit will have 
no problem getting into the 'haus should the team decides to take this option, 
younger or starting projects can have a hard time.

 
Regarding fluent interfaces and their possible mix with Java, then Groovy. Your 
example looks great, here's another option following the builder pattern:

dataset()
    .table("owners")

        .col("id", "first_name", "last_name", "address", "city", "telephone")
        .row("1", "Mandy", "Smith"      , "12 Oxford Street", "Southfield", 
"555-1234567")
        .row("2", "Joe"  , "Jeffries"   , "25 Baywater Lane", "Northbrook", 
"555-2345678")
        .row("3", "Herb" , "Dalton"     , "2 Main St"       , "Southfield", 
"555-3456789")
        .row("4", "Dave" , "Smith-Jones", "12 Kent Way"     , "Southfield", 
"555-4567890")    .table("pets")
        .col("id")
    .table("visits")
        .col("id")
     .build()

This one assumes an internal state machine is in place so that you can't call 
col().row().col()
Examples of such implementations can be found in Trident's 
InterpolatedPropertyBuilder and in FEST's APIs (100% Java code both).
What we do in Groovy otoh is write a POJO for each node, then let the builder 
manage their relationships (essentially becoming the state machine). Coding to 
POJOs makes the work really easy, that's how Groovy's SwingBuilder came to be so 
flexible.

Cheers,
Andres

-------------------------------------------
http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and 
those who don't.
To understand recursion, we must first understand recursion.




________________________________
From: John Hurst <joh...@gm...>
To: dbu...@li...
Sent: Tue, August 31, 2010 10:14:04 PM
Subject: [dbunit-developer] CodeHaus?

Andres,

Nice to see you following this list! You rock!

What is involved in getting a project accepted into CodeHaus?

With regard to Groovy, I am on the lookout for ways to make DbUnit more seamless 
with Groovy.

Regards


John Hurst
-- 
Life is interfering with my game



      

[dbunit-developer] "fluent" API

[John H. <joh...@gm...>]

Here's what I regard as a "fluent" approach to DbUnit datasets and testing.
I'm not sure whether "fluent" is the correct word, but here goes:

public class InlineSelectOwnerTest extends DBTestCase {

  protected IDataSet getDataSet() throws Exception {
    return dataSet(
      table("owners",
        col("id", "first_name", "last_name", "address", "city",
"telephone"),
        row("1", "Mandy", "Smith"      , "12 Oxford Street", "Southfield",
"555-1234567"),
        row("2", "Joe"  , "Jeffries"   , "25 Baywater Lane", "Northbrook",
"555-2345678"),
        row("3", "Herb" , "Dalton"     , "2 Main St"       , "Southfield",
"555-3456789"),
        row("4", "Dave" , "Smith-Jones", "12 Kent Way"     , "Southfield",
"555-4567890")
      ),
      table("pets", col("id")),
      table("visits", col("id"))
    );
  }

//...
}

This example is one from the work I did on Java Power Tools. It uses Java 5
varargs and static import features, which is why I haven't promoted this
style into DbUnit core yet. But I would advocate this kind of API for DbUnit
3.0. (As one of many options.)

Regards

John Hurst

-- 
Life is interfering with my game

[dbunit-developer] CodeHaus?

[John H. <joh...@gm...>]

Andres,

Nice to see you following this list! You rock!

What is involved in getting a project accepted into CodeHaus?

With regard to Groovy, I am on the lookout for ways to make DbUnit more
seamless with Groovy.

Regards

John Hurst

-- 
Life is interfering with my game

[dbunit-developer] JDBC4 features

[John H. <joh...@gm...>]

Roberto,

Another issue relating to JDBC4 is that many JDBC drivers may not yet
support the JDBC4 features.

I started looking at JDBC4 features myself a little while ago. For example,
there was a nice little article on IBM developerWorks recently by Ted
Neward.

However, I don't recall seeing any features that struck me as particularly
relevant to DbUnit. Did you have any in mind?

Regards

John Hurst

-- 
Life is interfering with my game

Re: [dbunit-developer] DbUnit 3.0 - Infrastructure (Wiki, CI, VCS)

[Roberto Lo G. <rlo...@gm...>]

On Tue, Aug 31, 2010 at 14:55, Andres Almiray <aal...@ya...> wrote:

> About hosting the Wiki, CI and VCS, have you considered The Codehaus? It
> comes with Confluence, Jira,  and Bamboo. It even supports Git for over a
> year now (besides SVN).
>
> +1 on moving the codebase to jdk5 or better, however I would be weary to
> move it to Jdk6 even if Jdk5 is EOL, as enterprises are really slow in
> moving. Jdk5 will still be with us for a few more years (paid support or
> not).
>

I understand your point of view but JDBC 4 feature could ease our work and
give us simple solutions to old problems... If the enterprises are stuck to
Java 5 and we decide to use Java 6 and JDBC 4.... they can continue to use
the 2.x branch until they are ready to move on.... The message is we are
thinking to the next gen, enterprises will not move to 3.0 right on its
first release :-)

+1 on builders and fluent interfaces. Anything that makes me productive with
> plain Java code while writing less is great in my book. If those facilities
> can be combined with other JVM languages the better (this does not mean that
> DbUnit should have an officially supported Groovy/Scala/Clojure module
> unless someone wants to carry the torch).
>

Do you want to highlight some points where such patterns could be a booster?


>
> My $0.02
>
> -------------------------------------------
> http://jroller.com/aalmiray
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
>
> ------------------------------
> *From:* Roberto Lo Giacco <rlo...@gm...>
> *To:* dbu...@li...
> *Sent:* Tue, August 31, 2010 12:23:50 PM
> *Subject:* Re: [dbunit-developer] DbUnit 3.0 - Infrastructure (Wiki, CI,
> VCS)
>
>
>
> On Tue, Aug 31, 2010 at 11:15, John Hurst <joh...@gm...> wrote:
>
>> I think we should go for it. I only mentioned Git as an idea -- if
>> everyone was already comfortable with Git it might be a no-brainer. If
>> people aren't we can continue with Subversion. As I said I don't want to
>> slow down the main objective here. (I will mention that I do most of my own
>> DbUnit work on a Git clone of the svn repository, and apply the work back to
>> svn trunk via patches from Git. I prefer that because it allows me to have
>> private branches for my work.)
>
>
> Private branches... it looks similar to ClearCase, which I had a bad
> experience recently... I'm not vetoing about Git, I just do not have any
> experience: this is both a pro and a con for me, I like to learn but this
> will take time and errors. Let the majority decide, for me is 0 (abstention)
>
> Regarding DbUnit 3 discussion: Are we using the wiki to record the design
>> requirements/decisions? Jeff and I added some content there for the DbUnit 3
>> roadmap in January, but I don't think anyone else has been in there since.
>> Looking at it now, I believe that the roadmap shows most of what I can think
>> of. Perhaps Roberto you would like to review that and amend it with your
>> ideas/plans, or else post back here what you'd like to cover aside from what
>> we already put on the wiki?
>>
>
> I would prefer to talk on the list before taking any decision and thus
> posting on the wiki: I think we would end up only messing that page. Here
> are my considerations:
>
>  Java 5.0 Compatible
>
>    - Consider 6 as 5 is already EOL (OK, but what is different about 6
>    from 5? JDBC 4.0? Any other differences relevant to DbUnit?) +1
>    - Generics +1
>    - Annotations +1 (we can use them to avoid inheritance issues, it could
>    be possible to annotate the test class or annotate methods to set the
>    dataset to use)
>    - Static imports + varargs for convenience methods, e.g. inline data
>    for tests? +1
>
> Rationalize DatabaseTestCase/DBTester
>
>    - Connection management +1 (annotations!)
>    - How to use DbUnit via composition rather than inheritance +1
>    (annotations can solve the problem)
>    - DbUnit should be natural to use from JUnit 3.8, JUnit 4.x or TestNG +/-0
>    (this may lead to get stuck somewhere)
>    - DbUnit should be natural to use in conjunction with Spring Test
>    Context framework and similar +1
>
> Consistency
>
>    - Builders applied consistently throughout code base (with fluent
>    interface) +1 (any suggestion/example?)
>    - Listeners/events applied consistently through code base (if indeed we
>    even use them!) +1 (I think they could be usefull, especially for
>    decorators)
>    - I/O applied consistently — InputStreamSources??? (from Spring
>    Resource Framework) Google Guava approach? +/- 0 (we should evaluate
>    pro and con)
>
> Cleanups
>
>    - Get rid of RowOutOfBoundsException anti-pattern +1
>    - Consistent, intuitive connection management (for those that do/don't
>    want rollback in tearDown(), etc) +1 (annotations)
>    - Change to using unchecked RuntimeExceptions? +/- 0 (pros? cons?)
>
> Use/Testing Ease
>
>    - Design use so is easier to create tests. +1
>       - load data files. +1
>       - easily work with DI containers. +1
>       - consider creating annotation set for tests. +1
>    - Add concept of "expected data". +1
>       - dbUnit already has "prep data" concept with getDataSet(). Since
>       most tests also have expected data, formally support it and differentiate
>       between the two, e.g. getPrepData(), getExpectedData(). +1 (we
>       should print the datas not matching)
>       - continue concept of CompositeDataSet - ability to merge multiple
>       source data sets into one. This is important when organizing common data
>       sets for prep and expected. +1
>    - Easy to use a product's DAOs, JPA, etc. vs special SQL for dbUnit +1
>
>
>> Regards
>>
>> John Hurst
>>
>> On Tue, Aug 31, 2010 at 9:00 PM, Roberto Lo Giacco <rlo...@gm...>wrote:
>>
>>>
>>>
>>> On Mon, Aug 30, 2010 at 22:05, John Hurst <joh...@gm...>wrote:
>>>
>>>> Version Control
>>>>
>>>> Finally, VCS. I've come to believe that distributed systems, such as
>>>> Git, are considerably more suitable for open-source projects than
>>>> Subversion. Don't get me wrong: unlike many Git users, I'm still a
>>>> Subversion fan. (We use it where I work and are very happy with it.) But
>>>> I've found that Git is much better for open-source work. For example, a
>>>> non-committer can check out a clone and work on a private branch very
>>>> conveniently. Using GitHub, it's possible to contribute elaborate patches
>>>> back to the main code base in a powerful way.
>>>>
>>>> If others feel similarly about DVCS, perhaps we should move the code
>>>> base to Git. GitHub also offers a pretty nice Wiki facility. However, it
>>>> seems SourceForge also supports Git.
>>>>
>>>
>>> I just have no experience as developer on Git... I'm still a Subversion
>>> guy too
>>>
>>>
>>>
>>>> I understand that Roberto would like to move this phase of the project
>>>> ahead *very* quickly. (One week of discussion, two weeks of coding.) I don't
>>>> want to slow this process down with extraneous worries about infrastructure.
>>>>
>>>
>>> Well, don't consider those timing a constraint, I just wished to have a
>>> quick first iteration.
>>> I don't think infrastructure is lesser important, but we had not solved
>>> those historical problems in the last months and I do not think we'll be
>>> able to fix all of them in a very short time....
>>>
>>> I'm not giving up on those infrastructure upgrade/improvement, but I do
>>> not want to get stuck on them. You can see by yourself: we spent more emails
>>> on this arguments rather than on 3.0 design/features.... Do you think we
>>> need a 3.x at all? May be I'm the wrong one....
>>>
>>>
>>>>
>>>> Just my thoughts.
>>>>
>>>> John Hurst
>>>>
>>>> --
>>>> Life is interfering with my game
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net Dev2Dev email is sponsored by:
>>>>
>>>> Show off your parallel programming skills.
>>>> Enter the Intel(R) Threading Challenge 2010.
>>>> http://p.sf.net/sfu/intel-thread-sfd
>>>> _______________________________________________
>>>> dbunit-developer mailing list
>>>>
>>>> dbu...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net Dev2Dev email is sponsored by:
>>>
>>> Show off your parallel programming skills.
>>> Enter the Intel(R) Threading Challenge 2010.
>>> http://p.sf.net/sfu/intel-thread-sfd
>>> _______________________________________________
>>> dbunit-developer mailing list
>>> dbu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>>
>>>
>>
>>
>> --
>> Life is interfering with my game
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> dbunit-developer mailing list
>> dbu...@li...
>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>

Re: [dbunit-developer] DbUnit 3.0 - Infrastructure (Wiki, CI, VCS)

[Andres A. <aal...@ya...>]

About hosting the Wiki, CI and VCS, have you considered The Codehaus? It comes 
with Confluence, Jira,  and Bamboo. It even supports Git for over a year now 
(besides SVN).

+1 on moving the codebase to jdk5 or better, however I would be weary to move it 
to Jdk6 even if Jdk5 is EOL, as enterprises are really slow in moving. Jdk5 will 
still be with us for a few more years (paid support or not).

+1 on builders and fluent interfaces. Anything that makes me productive with 
plain Java code while writing less is great in my book. If those facilities can 
be combined with other JVM languages the better (this does not mean that DbUnit 
should have an officially supported Groovy/Scala/Clojure module unless someone 
wants to carry the torch).

 
My $0.02

-------------------------------------------
http://jroller.com/aalmiray
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and 
those who don't.
To understand recursion, we must first understand recursion.




________________________________
From: Roberto Lo Giacco <rlo...@gm...>
To: dbu...@li...
Sent: Tue, August 31, 2010 12:23:50 PM
Subject: Re: [dbunit-developer] DbUnit 3.0 - Infrastructure (Wiki, CI, VCS)




On Tue, Aug 31, 2010 at 11:15, John Hurst <joh...@gm...> wrote:

I think we should go for it. I only mentioned Git as an idea -- if everyone was 
already comfortable with Git it might be a no-brainer. If people aren't we can 
continue with Subversion. As I said I don't want to slow down the main objective 
here. (I will mention that I do most of my own DbUnit work on a Git clone of the 
svn repository, and apply the work back to svn trunk via patches from Git. I 
prefer that because it allows me to have private branches for my work.)

Private branches... it looks similar to ClearCase, which I had a bad experience 
recently... I'm not vetoing about Git, I just do not have any experience: this 
is both a pro and a con for me, I like to learn but this will take time and 
errors. Let the majority decide, for me is 0 (abstention)

Regarding DbUnit 3 discussion: Are we using the wiki to record the design 
requirements/decisions? Jeff and I added some content there for the DbUnit 3 
roadmap in January, but I don't think anyone else has been in there since. 
Looking at it now, I believe that the roadmap shows most of what I can think of. 
Perhaps Roberto you would like to review that and amend it with your 
ideas/plans, or else post back here what you'd like to cover aside from what we 
already put on the wiki?

I would prefer to talk on the list before taking any decision and thus posting 
on the wiki: I think we would end up only messing that page. Here are my 
considerations:

Java 5.0 Compatible
	* Consider 6 as 5 is already EOL (OK, but what is different about 6 from 5? 
JDBC 4.0? Any other differences relevant to DbUnit?) +1
	* Generics +1
	* Annotations +1 (we can use them to avoid inheritance issues, it could be 
possible to annotate the test class or annotate methods to set the dataset to 
use)
	* Static imports + varargs for convenience methods, e.g. inline data for 
tests? +1
Rationalize DatabaseTestCase/DBTester
	* Connection management +1 (annotations!)
	* How to use DbUnit via composition rather than inheritance +1 (annotations can 
solve the problem)
	* DbUnit should be natural to use from JUnit 3.8, JUnit 4.x or TestNG +/-0 
(this may lead to get stuck somewhere)
	* DbUnit should be natural to use in conjunction with Spring Test Context 
framework and similar +1
Consistency
	* Builders applied consistently throughout code base (with fluent interface) +1 
(any suggestion/example?)
	* Listeners/events applied consistently through code base (if indeed we even 
use them!) +1 (I think they could be usefull, especially for decorators)
	* I/O applied consistently — InputStreamSources??? (from Spring Resource 
Framework) Google Guava approach? +/- 0 (we should evaluate pro and con)
Cleanups
	* Get rid of RowOutOfBoundsException anti-pattern +1
	* Consistent, intuitive connection management (for those that do/don't want 
rollback in tearDown(), etc) +1 (annotations)
	* Change to using unchecked RuntimeExceptions? +/- 0 (pros? cons?)
Use/Testing Ease
	* Design use so is easier to create tests. +1
	* load data files. +1
	* easily work with DI containers. +1
	* consider creating annotation set for tests. +1
	* Add concept of "expected data". +1
	* dbUnit already has "prep data" concept with getDataSet(). Since most tests 
also have expected data, formally support it and differentiate between the two, 
e.g. getPrepData(), getExpectedData(). +1 (we should print the datas not 
matching)
	* continue concept of CompositeDataSet - ability to merge multiple source data 
sets into one. This is important when organizing common data sets for prep and 
expected. +1
	* Easy to use a product's DAOs, JPA, etc. vs special SQL for dbUnit +1

>
>Regards
>
>John Hurst
>
>
>On Tue, Aug 31, 2010 at 9:00 PM, Roberto Lo Giacco <rlo...@gm...> wrote:
>
>
>>
>>
>>On Mon, Aug 30, 2010 at 22:05, John Hurst <joh...@gm...> wrote:
>>
>>Version Control
>>>
>>>
>>>Finally, VCS. I've come to believe that distributed systems, such as Git, are 
>>>considerably more suitable for open-source projects than Subversion. Don't get 
>>>me wrong: unlike many Git users, I'm still a Subversion fan. (We use it where I 
>>>work and are very happy with it.) But I've found that Git is much better for 
>>>open-source work. For example, a non-committer can check out a clone and work on 
>>>a private branch very conveniently. Using GitHub, it's possible to contribute 
>>>elaborate patches back to the main code base in a powerful way.
>>>
>>>
>>>If others feel similarly about DVCS, perhaps we should move the code base to 
>>>Git. GitHub also offers a pretty nice Wiki facility. However, it seems 
>>>SourceForge also supports Git.
>
>
>>I just have no experience as developer on Git... I'm still a Subversion guy 
too
>>
>>
>> 
>>I understand that Roberto would like to move this phase of the project ahead 
>>*very* quickly. (One week of discussion, two weeks of coding.) I don't want to 
>>slow this process down with extraneous worries about infrastructure.
>
>
>>Well, don't consider those timing a constraint, I just wished to have a quick 
>>first iteration. 
>>I don't think infrastructure is lesser important, but we had not solved those 
>>historical problems in the last months and I do not think we'll be able to fix 
>>all of them in a very short time.... 
>>
>>
>>I'm not giving up on those infrastructure upgrade/improvement, but I do not want 
>>to get stuck on them. You can see by yourself: we spent more emails on this 
>>arguments rather than on 3.0 design/features.... Do you think we need a 3.x at 
>>all? May be I'm the wrong one.... 
>> 
>>
>>>
>>>Just my thoughts.
>>>
>>>
>>>John Hurst
>>>
>>>-- 
>>>Life is interfering with my game
>>>
>>>------------------------------------------------------------------------------

>>>This SF.net Dev2Dev email is sponsored by:
>>>
>>>Show off your parallel programming skills.
>>>Enter the Intel(R) Threading Challenge 2010.
>>>http://p.sf.net/sfu/intel-thread-sfd
>>>_______________________________________________
>>>dbunit-developer mailing list
>>>
>>>dbu...@li...
>>>https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>>
>>>
>>
>>------------------------------------------------------------------------------
>>This SF.net Dev2Dev email is sponsored by:
>>
>>Show off your parallel programming skills.
>>Enter the Intel(R) Threading Challenge 2010.
>>http://p.sf.net/sfu/intel-thread-sfd
>>_______________________________________________
>>dbunit-developer mailing list
>>dbu...@li...
>>https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>
>>
>
>
>-- 
>Life is interfering with my game
>
>------------------------------------------------------------------------------
>This SF.net Dev2Dev email is sponsored by:
>
>Show off your parallel programming skills.
>Enter the Intel(R) Threading Challenge 2010.
>http://p.sf.net/sfu/intel-thread-sfd
>_______________________________________________
>dbunit-developer mailing list
>dbu...@li...
>https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>



      

Re: [dbunit-developer] DbUnit 3.0: Table/Structure

[Roberto Lo G. <rlo...@gm...>]

On Tue, Aug 31, 2010 at 12:05, John Hurst <joh...@gm...> wrote:

> Yes, those name changes would be consistent and suitable, assuming that the
> Structure/Property model actually can be made to suit useful alternative
> data sources. I think before we commit to this change for DbUnit 3, there
> needs to be at least one nonrelational data source that we agree to support,
> preferably more. Do you have systems using LDAP for which you could set up
> potential DbUnit tests?


Actually no, but I think any authentication system may need something like
that. I just wanted us to consider the option, I heve no need for it and I'm
not sure it would benefit the library.

>
> Regarding XML, I was not talking about performance. Performance seems to
> have been an issue for some users. There is evidence of performance-oriented
> code in the DbUnit code base, for example in the streaming code. But this
> has never been an issue for me.
>

I know you were not speaking about performance, it was something emerged as
I was thinking about XML and I remind some items in the tracker about
performances... My usage of the library is very similar to yours: I never
had performance problems because I do not use DbUnit for performance tests.

My own usage of DbUnit almost always uses a relatively small number of rows
> per test. My focus is on clarity and ease of writing tests, not on
> performance. When I said "optimize" I was talking about in relation to these
> concerns, not about performance. So for me XML is a poor choice of
> representation, because I generally want tabular data. (For non-tabular data
> XML will likely be a pretty good "default" format, thanks to its
> flexibility.) (I don't want to drop XML, I want alternatives that might work
> better in many cases.)
>

I perfectly understand your point but I do not have any idea about a
possible solution. We have XML, CSV and Excel... what should we can
consider? I do not know anything else among standards or standard proposals.


> Regards
>
> John Hurst
>
>
> On Tue, Aug 31, 2010 at 9:44 PM, Roberto Lo Giacco <rlo...@gm...>wrote:
>
>>
>> On Mon, Aug 30, 2010 at 22:27, John Hurst <joh...@gm...> wrote:
>>
>>> I've also been curious about whether DbUnit could support alternative
>>> data sources. (It would be nice to rename Database to DataSource, but that
>>> term already has a widely-accepted meaning in Java.)
>>
>>
>> I agree both on the DataSource term and about the approach to the
>> argument: by the way, the support to non relational dbs could lead to a
>> project name change too...
>>
>>
>>
>>> Another area for consideration of this is the NoSQL databases -- now all
>>> the rage.
>>>
>>> But it seems to me that DbUnit is very much about tabular data. You would
>>> like to rename ITable? But consider the methods:
>>>   ITableMetaData getTableMetaData()
>>>   int getRowCount()
>>>   Object getValue(int row, String column)
>>>
>>> And ITableMetaData:
>>>   String getTableName()
>>>   Column[] getColumns()
>>>   Column[] getPrimaryKeys()
>>>   int getColumnIndex(String columnName)
>>>
>>> These are very much about tables. I would be interested to hear whether
>>> you think these interfaces would apply well to LDAP (or a NoSQL database).
>>>
>>
>> What about the following renaming schema:
>>
>> ITable --> DataStructure
>> ITableMetaData --> DataStructureMetaData
>> ITable.getTableMetaData() --> DataStructure.getMetaData()
>> ITable.getRowCount() --> DataStructure.getItemsCount()
>> ITable.getValue(int row, String column) --> DataStructure.getValue(int
>> index, String propertyName)
>> ITableMetaData.getTableName() --> DataStructureMetaData.getStructureName()
>> Column --> Property
>> ITableMetaData.getColumns() --> DataStructureMetaData.getProperties()
>> ITableMetaData.getPrimaryKeys()
>> -->  --> DataStructureMetaData.getPrimaryKeys()
>> ITableMetaData.getColumnIndex(String columnName)
>> --> DataStructureMetaData.getPropertyIndex(propertyName)
>>
>>>
>>> To me, a major challenge for DbUnit is optimizing the representation of
>>> tabular test data. XML for example, the de-facto standard DbUnit input
>>> format, is notoriously bad for representing tabular data. CSV is much
>>> better, but has its own limitations. Most of my work with DbUnit has been to
>>> make tabular test data more concise and readable, to make tests clearer and
>>> easier to write. It's a usability issue, rather than one of flexibility.
>>>
>>
>> I think we should improve the format too but stick to XML as main format,
>> may be allowing for any kind of binary representation whenever performance
>> is an issue: the latter format can reduce the load phase time avoiding the
>> parsing phase. This binary format can be obtained by "compiling" one of the
>> other source formats.
>>
>> You see? Just talking about we  ended in another potential feature!
>>
>>
>>>
>>> Regards
>>>
>>> John Hurst
>>>
>>> --
>>> Life is interfering with my game
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net Dev2Dev email is sponsored by:
>>>
>>> Show off your parallel programming skills.
>>> Enter the Intel(R) Threading Challenge 2010.
>>> http://p.sf.net/sfu/intel-thread-sfd
>>> _______________________________________________
>>> dbunit-developer mailing list
>>> dbu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> dbunit-developer mailing list
>> dbu...@li...
>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>
>>
>
>
> --
> Life is interfering with my game
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>

Re: [dbunit-developer] DbUnit 3.0 - Infrastructure (Wiki, CI, VCS)

[Roberto Lo G. <rlo...@gm...>]

On Tue, Aug 31, 2010 at 11:15, John Hurst <joh...@gm...> wrote:

> I think we should go for it. I only mentioned Git as an idea -- if everyone
> was already comfortable with Git it might be a no-brainer. If people aren't
> we can continue with Subversion. As I said I don't want to slow down the
> main objective here. (I will mention that I do most of my own DbUnit work on
> a Git clone of the svn repository, and apply the work back to svn trunk via
> patches from Git. I prefer that because it allows me to have private
> branches for my work.)


Private branches... it looks similar to ClearCase, which I had a bad
experience recently... I'm not vetoing about Git, I just do not have any
experience: this is both a pro and a con for me, I like to learn but this
will take time and errors. Let the majority decide, for me is 0 (abstention)

Regarding DbUnit 3 discussion: Are we using the wiki to record the design
> requirements/decisions? Jeff and I added some content there for the DbUnit 3
> roadmap in January, but I don't think anyone else has been in there since.
> Looking at it now, I believe that the roadmap shows most of what I can think
> of. Perhaps Roberto you would like to review that and amend it with your
> ideas/plans, or else post back here what you'd like to cover aside from what
> we already put on the wiki?
>

I would prefer to talk on the list before taking any decision and thus
posting on the wiki: I think we would end up only messing that page. Here
are my considerations:

 Java 5.0 Compatible

   - Consider 6 as 5 is already EOL (OK, but what is different about 6 from
   5? JDBC 4.0? Any other differences relevant to DbUnit?) +1
   - Generics +1
   - Annotations +1 (we can use them to avoid inheritance issues, it could
   be possible to annotate the test class or annotate methods to set the
   dataset to use)
   - Static imports + varargs for convenience methods, e.g. inline data for
   tests? +1

Rationalize DatabaseTestCase/DBTester

   - Connection management +1 (annotations!)
   - How to use DbUnit via composition rather than inheritance +1
   (annotations can solve the problem)
   - DbUnit should be natural to use from JUnit 3.8, JUnit 4.x or TestNG +/-0
   (this may lead to get stuck somewhere)
   - DbUnit should be natural to use in conjunction with Spring Test Context
   framework and similar +1

Consistency

   - Builders applied consistently throughout code base (with fluent
   interface) +1 (any suggestion/example?)
   - Listeners/events applied consistently through code base (if indeed we
   even use them!) +1 (I think they could be usefull, especially for
   decorators)
   - I/O applied consistently — InputStreamSources??? (from Spring Resource
   Framework) Google Guava approach? +/- 0 (we should evaluate pro and con)

Cleanups

   - Get rid of RowOutOfBoundsException anti-pattern +1
   - Consistent, intuitive connection management (for those that do/don't
   want rollback in tearDown(), etc) +1 (annotations)
   - Change to using unchecked RuntimeExceptions? +/- 0 (pros? cons?)

Use/Testing Ease

   - Design use so is easier to create tests. +1
      - load data files. +1
      - easily work with DI containers. +1
      - consider creating annotation set for tests. +1
   - Add concept of "expected data". +1
      - dbUnit already has "prep data" concept with getDataSet(). Since most
      tests also have expected data, formally support it and
differentiate between
      the two, e.g. getPrepData(), getExpectedData(). +1 (we should print
      the datas not matching)
      - continue concept of CompositeDataSet - ability to merge multiple
      source data sets into one. This is important when organizing common data
      sets for prep and expected. +1
   - Easy to use a product's DAOs, JPA, etc. vs special SQL for dbUnit +1


> Regards
>
> John Hurst
>
> On Tue, Aug 31, 2010 at 9:00 PM, Roberto Lo Giacco <rlo...@gm...>wrote:
>
>>
>>
>> On Mon, Aug 30, 2010 at 22:05, John Hurst <joh...@gm...> wrote:
>>
>>> Version Control
>>>
>>> Finally, VCS. I've come to believe that distributed systems, such as Git,
>>> are considerably more suitable for open-source projects than Subversion.
>>> Don't get me wrong: unlike many Git users, I'm still a Subversion fan. (We
>>> use it where I work and are very happy with it.) But I've found that Git is
>>> much better for open-source work. For example, a non-committer can check out
>>> a clone and work on a private branch very conveniently. Using GitHub, it's
>>> possible to contribute elaborate patches back to the main code base in a
>>> powerful way.
>>>
>>> If others feel similarly about DVCS, perhaps we should move the code base
>>> to Git. GitHub also offers a pretty nice Wiki facility. However, it seems
>>> SourceForge also supports Git.
>>>
>>
>> I just have no experience as developer on Git... I'm still a Subversion
>> guy too
>>
>>
>>
>>> I understand that Roberto would like to move this phase of the project
>>> ahead *very* quickly. (One week of discussion, two weeks of coding.) I don't
>>> want to slow this process down with extraneous worries about infrastructure.
>>>
>>
>> Well, don't consider those timing a constraint, I just wished to have a
>> quick first iteration.
>> I don't think infrastructure is lesser important, but we had not solved
>> those historical problems in the last months and I do not think we'll be
>> able to fix all of them in a very short time....
>>
>> I'm not giving up on those infrastructure upgrade/improvement, but I do
>> not want to get stuck on them. You can see by yourself: we spent more emails
>> on this arguments rather than on 3.0 design/features.... Do you think we
>> need a 3.x at all? May be I'm the wrong one....
>>
>>
>>>
>>> Just my thoughts.
>>>
>>> John Hurst
>>>
>>> --
>>> Life is interfering with my game
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net Dev2Dev email is sponsored by:
>>>
>>> Show off your parallel programming skills.
>>> Enter the Intel(R) Threading Challenge 2010.
>>> http://p.sf.net/sfu/intel-thread-sfd
>>> _______________________________________________
>>> dbunit-developer mailing list
>>>
>>> dbu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> dbunit-developer mailing list
>> dbu...@li...
>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>
>>
>
>
> --
> Life is interfering with my game
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>

Re: [dbunit-developer] DbUnit 3.0: Table/Structure

[John H. <joh...@gm...>]

Yes, those name changes would be consistent and suitable, assuming that the
Structure/Property model actually can be made to suit useful alternative
data sources. I think before we commit to this change for DbUnit 3, there
needs to be at least one nonrelational data source that we agree to support,
preferably more. Do you have systems using LDAP for which you could set up
potential DbUnit tests?

Regarding XML, I was not talking about performance. Performance seems to
have been an issue for some users. There is evidence of performance-oriented
code in the DbUnit code base, for example in the streaming code. But this
has never been an issue for me.

My own usage of DbUnit almost always uses a relatively small number of rows
per test. My focus is on clarity and ease of writing tests, not on
performance. When I said "optimize" I was talking about in relation to these
concerns, not about performance. So for me XML is a poor choice of
representation, because I generally want tabular data. (For non-tabular data
XML will likely be a pretty good "default" format, thanks to its
flexibility.) (I don't want to drop XML, I want alternatives that might work
better in many cases.)

Regards

John Hurst

On Tue, Aug 31, 2010 at 9:44 PM, Roberto Lo Giacco <rlo...@gm...>wrote:

>
> On Mon, Aug 30, 2010 at 22:27, John Hurst <joh...@gm...> wrote:
>
>> I've also been curious about whether DbUnit could support alternative data
>> sources. (It would be nice to rename Database to DataSource, but that term
>> already has a widely-accepted meaning in Java.)
>
>
> I agree both on the DataSource term and about the approach to the argument:
> by the way, the support to non relational dbs could lead to a project name
> change too...
>
>
>
>> Another area for consideration of this is the NoSQL databases -- now all
>> the rage.
>>
>> But it seems to me that DbUnit is very much about tabular data. You would
>> like to rename ITable? But consider the methods:
>>   ITableMetaData getTableMetaData()
>>   int getRowCount()
>>   Object getValue(int row, String column)
>>
>> And ITableMetaData:
>>   String getTableName()
>>   Column[] getColumns()
>>   Column[] getPrimaryKeys()
>>   int getColumnIndex(String columnName)
>>
>> These are very much about tables. I would be interested to hear whether
>> you think these interfaces would apply well to LDAP (or a NoSQL database).
>>
>
> What about the following renaming schema:
>
> ITable --> DataStructure
> ITableMetaData --> DataStructureMetaData
> ITable.getTableMetaData() --> DataStructure.getMetaData()
> ITable.getRowCount() --> DataStructure.getItemsCount()
> ITable.getValue(int row, String column) --> DataStructure.getValue(int
> index, String propertyName)
> ITableMetaData.getTableName() --> DataStructureMetaData.getStructureName()
> Column --> Property
> ITableMetaData.getColumns() --> DataStructureMetaData.getProperties()
> ITableMetaData.getPrimaryKeys()
> -->  --> DataStructureMetaData.getPrimaryKeys()
> ITableMetaData.getColumnIndex(String columnName)
> --> DataStructureMetaData.getPropertyIndex(propertyName)
>
>>
>> To me, a major challenge for DbUnit is optimizing the representation of
>> tabular test data. XML for example, the de-facto standard DbUnit input
>> format, is notoriously bad for representing tabular data. CSV is much
>> better, but has its own limitations. Most of my work with DbUnit has been to
>> make tabular test data more concise and readable, to make tests clearer and
>> easier to write. It's a usability issue, rather than one of flexibility.
>>
>
> I think we should improve the format too but stick to XML as main format,
> may be allowing for any kind of binary representation whenever performance
> is an issue: the latter format can reduce the load phase time avoiding the
> parsing phase. This binary format can be obtained by "compiling" one of the
> other source formats.
>
> You see? Just talking about we  ended in another potential feature!
>
>
>>
>> Regards
>>
>> John Hurst
>>
>> --
>> Life is interfering with my game
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> dbunit-developer mailing list
>> dbu...@li...
>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>


-- 
Life is interfering with my game

Re: [dbunit-developer] DbUnit 3.0: Table/Structure

[Roberto Lo G. <rlo...@gm...>]

On Mon, Aug 30, 2010 at 22:27, John Hurst <joh...@gm...> wrote:

> I've also been curious about whether DbUnit could support alternative data
> sources. (It would be nice to rename Database to DataSource, but that term
> already has a widely-accepted meaning in Java.)


I agree both on the DataSource term and about the approach to the argument:
by the way, the support to non relational dbs could lead to a project name
change too...



> Another area for consideration of this is the NoSQL databases -- now all
> the rage.
>
> But it seems to me that DbUnit is very much about tabular data. You would
> like to rename ITable? But consider the methods:
>   ITableMetaData getTableMetaData()
>   int getRowCount()
>   Object getValue(int row, String column)
>
> And ITableMetaData:
>   String getTableName()
>   Column[] getColumns()
>   Column[] getPrimaryKeys()
>   int getColumnIndex(String columnName)
>
> These are very much about tables. I would be interested to hear whether you
> think these interfaces would apply well to LDAP (or a NoSQL database).
>

What about the following renaming schema:

ITable --> DataStructure
ITableMetaData --> DataStructureMetaData
ITable.getTableMetaData() --> DataStructure.getMetaData()
ITable.getRowCount() --> DataStructure.getItemsCount()
ITable.getValue(int row, String column) --> DataStructure.getValue(int
index, String propertyName)
ITableMetaData.getTableName() --> DataStructureMetaData.getStructureName()
Column --> Property
ITableMetaData.getColumns() --> DataStructureMetaData.getProperties()
ITableMetaData.getPrimaryKeys()
-->  --> DataStructureMetaData.getPrimaryKeys()
ITableMetaData.getColumnIndex(String columnName)
--> DataStructureMetaData.getPropertyIndex(propertyName)

>
> To me, a major challenge for DbUnit is optimizing the representation of
> tabular test data. XML for example, the de-facto standard DbUnit input
> format, is notoriously bad for representing tabular data. CSV is much
> better, but has its own limitations. Most of my work with DbUnit has been to
> make tabular test data more concise and readable, to make tests clearer and
> easier to write. It's a usability issue, rather than one of flexibility.
>

I think we should improve the format too but stick to XML as main format,
may be allowing for any kind of binary representation whenever performance
is an issue: the latter format can reduce the load phase time avoiding the
parsing phase. This binary format can be obtained by "compiling" one of the
other source formats.

You see? Just talking about we  ended in another potential feature!


>
> Regards
>
> John Hurst
>
> --
> Life is interfering with my game
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>

Re: [dbunit-developer] DbUnit 3.0 - Infrastructure (Wiki, CI, VCS)

[John H. <joh...@gm...>]

I think we should go for it. I only mentioned Git as an idea -- if everyone
was already comfortable with Git it might be a no-brainer. If people aren't
we can continue with Subversion. As I said I don't want to slow down the
main objective here. (I will mention that I do most of my own DbUnit work on
a Git clone of the svn repository, and apply the work back to svn trunk via
patches from Git. I prefer that because it allows me to have private
branches for my work.)

Regarding DbUnit 3 discussion: Are we using the wiki to record the design
requirements/decisions? Jeff and I added some content there for the DbUnit 3
roadmap in January, but I don't think anyone else has been in there since.
Looking at it now, I believe that the roadmap shows most of what I can think
of. Perhaps Roberto you would like to review that and amend it with your
ideas/plans, or else post back here what you'd like to cover aside from what
we already put on the wiki?

Regards

John Hurst

On Tue, Aug 31, 2010 at 9:00 PM, Roberto Lo Giacco <rlo...@gm...>wrote:

>
>
> On Mon, Aug 30, 2010 at 22:05, John Hurst <joh...@gm...> wrote:
>
>> Version Control
>>
>> Finally, VCS. I've come to believe that distributed systems, such as Git,
>> are considerably more suitable for open-source projects than Subversion.
>> Don't get me wrong: unlike many Git users, I'm still a Subversion fan. (We
>> use it where I work and are very happy with it.) But I've found that Git is
>> much better for open-source work. For example, a non-committer can check out
>> a clone and work on a private branch very conveniently. Using GitHub, it's
>> possible to contribute elaborate patches back to the main code base in a
>> powerful way.
>>
>> If others feel similarly about DVCS, perhaps we should move the code base
>> to Git. GitHub also offers a pretty nice Wiki facility. However, it seems
>> SourceForge also supports Git.
>>
>
> I just have no experience as developer on Git... I'm still a Subversion guy
> too
>
>
>
>> I understand that Roberto would like to move this phase of the project
>> ahead *very* quickly. (One week of discussion, two weeks of coding.) I don't
>> want to slow this process down with extraneous worries about infrastructure.
>>
>
> Well, don't consider those timing a constraint, I just wished to have a
> quick first iteration.
> I don't think infrastructure is lesser important, but we had not solved
> those historical problems in the last months and I do not think we'll be
> able to fix all of them in a very short time....
>
> I'm not giving up on those infrastructure upgrade/improvement, but I do not
> want to get stuck on them. You can see by yourself: we spent more emails on
> this arguments rather than on 3.0 design/features.... Do you think we need a
> 3.x at all? May be I'm the wrong one....
>
>
>>
>> Just my thoughts.
>>
>> John Hurst
>>
>> --
>> Life is interfering with my game
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> dbunit-developer mailing list
>>
>> dbu...@li...
>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>


-- 
Life is interfering with my game

Re: [dbunit-developer] DbUnit 3.0 - Infrastructure (Wiki, CI, VCS)

[Roberto Lo G. <rlo...@gm...>]

On Mon, Aug 30, 2010 at 22:05, John Hurst <joh...@gm...> wrote:

> Version Control
>
> Finally, VCS. I've come to believe that distributed systems, such as Git,
> are considerably more suitable for open-source projects than Subversion.
> Don't get me wrong: unlike many Git users, I'm still a Subversion fan. (We
> use it where I work and are very happy with it.) But I've found that Git is
> much better for open-source work. For example, a non-committer can check out
> a clone and work on a private branch very conveniently. Using GitHub, it's
> possible to contribute elaborate patches back to the main code base in a
> powerful way.
>
> If others feel similarly about DVCS, perhaps we should move the code base
> to Git. GitHub also offers a pretty nice Wiki facility. However, it seems
> SourceForge also supports Git.
>

I just have no experience as developer on Git... I'm still a Subversion guy
too



> I understand that Roberto would like to move this phase of the project
> ahead *very* quickly. (One week of discussion, two weeks of coding.) I don't
> want to slow this process down with extraneous worries about infrastructure.
>

Well, don't consider those timing a constraint, I just wished to have a
quick first iteration.
I don't think infrastructure is lesser important, but we had not solved
those historical problems in the last months and I do not think we'll be
able to fix all of them in a very short time....

I'm not giving up on those infrastructure upgrade/improvement, but I do not
want to get stuck on them. You can see by yourself: we spent more emails on
this arguments rather than on 3.0 design/features.... Do you think we need a
3.x at all? May be I'm the wrong one....


>
> Just my thoughts.
>
> John Hurst
>
> --
> Life is interfering with my game
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>

Re: [dbunit-developer] Next step

[Roberto Lo G. <rlo...@gm...>]

On Tue, Aug 31, 2010 at 05:02, Jeff Jensen <jj...@ap...> wrote:

>
>
>
>
> *From:* Roberto Lo Giacco [mailto:rlo...@gm...]
> *Sent:* Monday, August 30, 2010 1:18 PM
> *To:* dbu...@li...
> *Subject:* Re: [dbunit-developer] Next step
>
>
>
> Hi Jeff, first one to answer, I hope others will follow.
>
> About your questions...
>
> On Mon, Aug 30, 2010 at 14:30, Jeff Jensen <jj...@ap...> wrote:
>
> What are your process proposals to do this?
>
>
>
> If you mean what procedure I suggest to move on the next step is the common
> one:
>
>    - a maximum one week discussion during while we draw the baselines and
>    start code some usage example
>    - a maximum coding effort of about two weeks to have the first alfa
>    release to share among developers and have feedbacks about the design
>    - refactor what's necessary and move to beta stage with a release for
>    power users
>
> I doubt it could be done that fast normally, but perhaps you will do a lot
> if you work on it full time (?).
>

I'm used to push hard on myself  :) But I was considering a large help by
the devs...


>   I first think of proper infrastructure to help with development success
> and
> users getting info & easily trying it:
>
>
>
> I perfectly understand your point but I currently do not have any server
> resource available as I quitted my job.  I would add an integration test
> machine (as already said many times on this list). I think we should not ask
> too much unless we already have a solution....
>
>
>
>  - where to house the docu notes you speak of?  SF wiki?
>
>
>
> Unless we have any other resource already available....
>
>
>
> Where/how/what do you plan on communicating requirements, architecture,
> design ideas to foster discussion?
>

By email in this initial stages, like we are doing right now, ending up with
documentation to summarize our discussions... But I'm more than open to
ideas, I just don't want to stuck the process because the tool we may need
is not yet available....


>
>
>
>
>  - need a CI setup; where/how can we do this?
>
>
>
> I think we can start without CI and in the meanwhile someone should
> volunteer to find one: we should write a bunch of working classes and test
> before CI having any sense...
>
>
>
> That answer surprises me.  It is a key piece to establish ASAP.  Keeps us
> in a known state, without wasting each other’s time on “what’s wrong?”,
> raises quality.  Plus, can run code coverage tools to ensure we are very
> high.  (otherwise, it’s more of the same – low coverage, no known and
> published state).
>
> I’ve done new projects enough to know retrofitting into an automated build
> and quality infrastructure has a lot more pain than when starting with it in
> place.
>

I think you misunderstood me or I wasn't clear enough (english is only my
second language ;->). I'm not saying a CI server is not needed, nor I'm
saying I do not want to have one from the very beginning of the 3.0 trunk,
I'm just saying we do not already have one and, as I said some lines above,
I don't want to see us stuck because we lack a tool: people had worked for
half a century in the IT without a CI server ;-)

I perfectly agree with your point of view, but what I was trying to say
about the "bunch of classes" thing is we could start running test manually
and concentrate on the very core of the library.


>
>
>
>
>   - perhaps my employer will lend us some server space & time for this...
> would you like me to check?
>
>
>
> It would be perfect, but if he wants something back we should discuss the
> request with the community ;-)
>
>
>
> Nothing  - it would be free.  I would set it up and we’d all have access.
> I’ll “volunteer” and check.  I don’t know of a current alternative option.
>

In this case it will be silly to reject the proposal! ;-) I think a Hudson
or Continuum installation (or whatever your employeer usually adopt) can be
perfect... don't you think so?


>
>
>
>
>  - need a nightly build that:
>   - builds & deploys snapshot
>   - generates & deploys Maven site
>
>
>
> I think we do not strictly require this to start but I agree we should have
> something on this topic
>
>
>
> Just have the CI server do it when its ready.
>

Yes, but we do not already have one ;-)


>
>
>
>
>     - add "3.0" link from 2.x main page to 3.0 main page
>
>
>
> I think we should delay this after we have cleared ourselve the idea beyond
> the 3.0, otherwise we would have nothing to write on that page :-)
>
>
>
> It would be the Maven site gen results and docs we create as we go.  It
> will continue to evolve.  Start with the generated contents from reports.
>
>
>
>
>
>  - it's past time to use Sonatype's OSS artifact hosting
>
>
>
> What do you mean?
>
>
>
> Hosting the snapshot & release repos there (see previous email discussions;
> you mentioned looking into it further); release repo automatically synced to
> central.
>

You are right. My fault.


>
>
>
>
> However, I'd first like to see the current trunk/2.4.8 released.
>
>
>
> I was away from the project for a couple of months but I thought you had
> everything you need and all the information to perform a release on your
> own... does the trunk need something particular I can help with?
>
>
>
> You said you want to do all the releases (see previous email discussions).
> Plus I would need shell access to deploy the site.
>

I think I expressed myself wrong. Anyway, I'll try to release in a few
hours, right after posting my resume around :-)


>
>
>
>
>  -----Original Message-----
> From: Roberto Lo Giacco [mailto:rlo...@gm...]
> Sent: Monday, August 30, 2010 4:43 AM
> To: dbUnit Developers List
> Subject: [dbunit-developer] Next step
>
> Hello all,
>
> this is my second or third call to move the project toward the next
> step, but this time I've some time to spend on the project as I
> quitted my previous job and I'm now looking for some other
> opportunity. I can spend this "forced vacancies" on the project but I
> wish to have both your moral and concrete support and I do not want to
> operate without you as I know the effort required to reach the target
> will be more than I can provide.
>
> The idea is to bring dbunit to the 3.0 generation. What's in my mind
> is a complete rewriting of the codebase with massive cleanup.
>
> A lot of code in dbunit is actually a replica of something other
> libraries provide in a cleaner and more reliable manner: we have a
> minimal internal xml, excel and csv writers/parsers, we have a complex
> internal exception management, we are stuck to Java 1.4 support and we
> miss Java 5 support for annotations and generics.
>
> What I suggest is to maintain the principles and major design of the
> framework while improving and refreshing it. I would like to start
> collecting the ideas posted on the tracker and drawing some class
> diagrams of the actual codebase. I've already prepared the latter, I
> would like some help on the former.
>
> The first thing I wish to discuss is the option to open the library to
> other data sources other than relational databases, like LDAP or
> object databases. I remind someone asked for such feature and I think
> we can achieve such target with an additional level of indirection
> which should be decided in the first stage.
>
> If we decide to support such different data sources I think we should
> rename Table to something not strictly related to rdbms, may be
> Structure could be an option, and Database (DatabaseTester,
> DatabaseTestCase, etc...) with Data (DataTester, DataTestCase, etc...)
> while other names can stay untouched, like Operation,
> OperationListener and DataSet.
>
> I think it would be a waste of time to go further in describing the
> idea if it's not shared by you and you can't/wan't support it so
> please, post your answers and comments.
>
> Roberto Lo Giacco
>
>
> ----------------------------------------------------------------------------
> --
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>

[dbunit-developer] DataTypeFactory selection

[Roberto Lo G. <rlo...@gm...>]

Actually we need a property to be setted to determine the
correct type mapping. We would like to improve on this topic for the next
3.x version.

Proposals are:


   - Determine the factory inspecting the class loader and looking for JDBC
   drivers
   - Determine the factory using the Connection and DatabaseMetaData
   - Simply rename DataTypeFactory concept to the Dialect concept to which
   more users are familiar

About the data mapping problem the following features could be a plus:

   - Allow users to specify a per dataset mapping through a properties file,
   xml schema, dtd, or xml attribute
   - Easier and more standard support for null values

Please review and add your ideas... they are more than welcome!

Re: [dbunit-developer] Next step

[Roberto Lo G. <rlo...@gm...>]

About modularization and dependencies I think we can consider our user base
no more scared by dependencies: maven and ivy have solved quite well the
dependencies problem.

About separating modules I thought we had already discussed that topic about
the current trunk and, unless we decide to expand dbunit coverage to non
relational data sources, I don't understand what's wrong with the current
solution.

Using class loading to determine the data factory could be a potential
problem source: what if my app needs two different connections to two
different databases? We could use the database meta data, but I do not think
those information are reliable, we should perform a test on different
drivers.... I'll post another message to the list about this.

On Tue, Aug 31, 2010 at 01:38, John Hurst <joh...@gm...> wrote:

> I agree with this (in general). I was going to write something along the
> same lines:
>
> 1) DbUnit 3.0 should be more modular, so that dependencies can be specific
> to modules. The Oracle one is a good example.
>
> 2) I think we should overhaul how the DataTypeFactory is set -- make it
> automatic if possible. It trips up a lot of people to have to set that
> property, we see it in the mailing list quite often. (I get tripped up
> myself!)
>
> I will have a look over the code to see whether it would be reasonable for
> DbUnit to determine the correct DataTypeFactory automatically.
>
> Regards
>
> John Hurst
>
>
> On Tue, Aug 31, 2010 at 11:21 AM, Zdeněk Vráblík <zd...@vr...>wrote:
>
>> Hi Roberto,
>>
>> One of the questions for 3.0 should be how to manage dependencies.
>>
>> There was discussion about oracle jdbc dependency. DbUnit project
>> depends on oracle jdbc. I think putting all dependencies into one
>> project will not be sustainable if more dependencies will be
>> introduced.
>>
>> I am not sure if I am able to describe in details, but I try.
>>
>> My suggestion:
>> The DbUnit should break into multiple jar files.
>> DbUnit kernel would be responsible for searching data types in class
>> path. This should avoid ClassNotFound exceptions for dbunit users
>> without any interest of using particular advanced functionality.
>> DataTypes would dynamically build data type factory according
>> available data types and database version. DbUnit user has to define
>> just database name and version which is used. This would avaoid
>> multiple Factories classes
>>
>> Each advanced data type would declare which database and from which
>> version is supported.
>>
>> Regards,
>> Zdenek
>>
>> On Mon, Aug 30, 2010 at 10:42 AM, Roberto Lo Giacco <rlo...@gm...>
>> wrote:
>> > Hello all,
>> >
>> > this is my second or third call to move the project toward the next
>> > step, but this time I've some time to spend on the project as I
>> > quitted my previous job and I'm now looking for some other
>> > opportunity. I can spend this "forced vacancies" on the project but I
>> > wish to have both your moral and concrete support and I do not want to
>> > operate without you as I know the effort required to reach the target
>> > will be more than I can provide.
>> >
>> > The idea is to bring dbunit to the 3.0 generation. What's in my mind
>> > is a complete rewriting of the codebase with massive cleanup.
>> >
>> > A lot of code in dbunit is actually a replica of something other
>> > libraries provide in a cleaner and more reliable manner: we have a
>> > minimal internal xml, excel and csv writers/parsers, we have a complex
>> > internal exception management, we are stuck to Java 1.4 support and we
>> > miss Java 5 support for annotations and generics.
>> >
>> > What I suggest is to maintain the principles and major design of the
>> > framework while improving and refreshing it. I would like to start
>> > collecting the ideas posted on the tracker and drawing some class
>> > diagrams of the actual codebase. I've already prepared the latter, I
>> > would like some help on the former.
>> >
>> > The first thing I wish to discuss is the option to open the library to
>> > other data sources other than relational databases, like LDAP or
>> > object databases. I remind someone asked for such feature and I think
>> > we can achieve such target with an additional level of indirection
>> > which should be decided in the first stage.
>> >
>> > If we decide to support such different data sources I think we should
>> > rename Table to something not strictly related to rdbms, may be
>> > Structure could be an option, and Database (DatabaseTester,
>> > DatabaseTestCase, etc...) with Data (DataTester, DataTestCase, etc...)
>> > while other names can stay untouched, like Operation,
>> > OperationListener and DataSet.
>> >
>> > I think it would be a waste of time to go further in describing the
>> > idea if it's not shared by you and you can't/wan't support it so
>> > please, post your answers and comments.
>> >
>> > Roberto Lo Giacco
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> > Be part of this innovative community and reach millions of netbook users
>> > worldwide. Take advantage of special opportunities to increase revenue
>> and
>> > speed time-to-market. Join now, and jumpstart your future.
>> > http://p.sf.net/sfu/intel-atom-d2d
>> > _______________________________________________
>> > dbunit-developer mailing list
>> > dbu...@li...
>> > https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> dbunit-developer mailing list
>> dbu...@li...
>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>
>
>
>
> --
> Life is interfering with my game
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>

Re: [dbunit-developer] DbUnit 3.0 - Infrastructure (Wiki, CI, VCS)

[Jeff J. <jj...@ap...>]

 

 

From: John Hurst [mailto:joh...@gm...] 
Sent: Monday, August 30, 2010 3:06 PM
To: dbu...@li...
Subject: [dbunit-developer] DbUnit 3.0 - Infrastructure (Wiki, CI, VCS)

 

My thoughts:

 

Wiki.

 

It would be great to get a really decent Wiki. The current one is a bit
hokey. I wonder if we could get a Confluence instance somehow? That's my
preferred wiki, although any suitably "rich" wiki would be OK.

 

I'm pretty keen on working on samples and documentation. I wrote a chapter
on DbUnit for the "Java Power Tools" book a couple of years ago. More
recently I've been working on some DbUnit samples (among other things) based
on the Eclipse BIRT sample database, which is a rather nice little database
for that kind of thing. 

 

Some questions that come up a lot could be better answered by reference to a
standard set of samples. For example, dealing with auto-generated keys. (I
myself haven't actually dealt with that problem, being an Oracle/PostgreSQL
guy mostly. But I would like to learn how to deal with it, and create some
nice samples showing it.)

 

Sounds good John!  

The "formal docs" could be in APT format too, generated to the site.

 

 

Continuous Integration/Testing

 

I feel bad for not following through with the CI work I started on. I still
would like to try to get some CI going on Amazon EC2, but this is more for
my own interest, and I'm not sure it is appropriate for the project
long-term. Some dedicated server space would probably be better. It is
tricky (from my perspective) to include support for testing on Windows
(SQL-Server). Probably all of the other databases can be set up on a single
Linux server for testing purposes.

 

It's interesting though to consider how many different versions of databases
to support in DbUnit integration testing. Most projects don't have this
problem, but for DbUnit it is very relevant. For example, there is every
reason to expect different behavior for datatypes (e.g. CLOBs) on Oracle
versions 9, 10 and 11. 

 

It's also interesting to consider whether there are licensing issues. I have
always believed that the OTN license for Oracle permitted unlimited use for
development purposes. A couple of weeks ago I had a big argument on the
subject with an Oracle marketing rep, who was trying to squeeze more money
out of our company. He said that the OTN was time-limited, only meant for
resellers, etc etc. I gave up on him as just being a marketing jerk. But it
is a bit of an issue for the commercial databases.

 

I can imagine having a "grid" setup for the integration tests.  This is very
complex - supporting many databases and ensuring the dbUnit code is correct.
Unit and integration tests will be critical to success.

 

 

Version Control

 

Finally, VCS. I've come to believe that distributed systems, such as Git,
are considerably more suitable for open-source projects than Subversion.
Don't get me wrong: unlike many Git users, I'm still a Subversion fan. (We
use it where I work and are very happy with it.) But I've found that Git is
much better for open-source work. For example, a non-committer can check out
a clone and work on a private branch very conveniently. Using GitHub, it's
possible to contribute elaborate patches back to the main code base in a
powerful way.

 

If others feel similarly about DVCS, perhaps we should move the code base to
Git. GitHub also offers a pretty nice Wiki facility. However, it seems
SourceForge also supports Git.

 

I understand that Roberto would like to move this phase of the project ahead
*very* quickly. (One week of discussion, two weeks of coding.) I don't want
to slow this process down with extraneous worries about infrastructure.

 

Git sounds good.  SF supports it.

And a few "extra" days of planning, discussion, etc. doesn't slow things
down, it speeds things up!

 

 

Just my thoughts.

 

John Hurst


-- 
Life is interfering with my game

Re: [dbunit-developer] Next step

[Jeff J. <jj...@ap...>]

 

 

From: Roberto Lo Giacco [mailto:rlo...@gm...] 
Sent: Monday, August 30, 2010 1:18 PM
To: dbu...@li...
Subject: Re: [dbunit-developer] Next step

 

Hi Jeff, first one to answer, I hope others will follow.

About your questions...

On Mon, Aug 30, 2010 at 14:30, Jeff Jensen <jj...@ap...> wrote:

What are your process proposals to do this?

 

If you mean what procedure I suggest to move on the next step is the common
one:

*	a maximum one week discussion during while we draw the baselines and
start code some usage example
*	a maximum coding effort of about two weeks to have the first alfa
release to share among developers and have feedbacks about the design
*	refactor what's necessary and move to beta stage with a release for
power users

I doubt it could be done that fast normally, but perhaps you will do a lot
if you work on it full time (?).



I first think of proper infrastructure to help with development success and
users getting info & easily trying it:

 

I perfectly understand your point but I currently do not have any server
resource available as I quitted my job.  I would add an integration test
machine (as already said many times on this list). I think we should not ask
too much unless we already have a solution....

 

 - where to house the docu notes you speak of?  SF wiki?

 

Unless we have any other resource already available.... 

 

Where/how/what do you plan on communicating requirements, architecture,
design ideas to foster discussion?

 

 

 - need a CI setup; where/how can we do this?

 

I think we can start without CI and in the meanwhile someone should
volunteer to find one: we should write a bunch of working classes and test
before CI having any sense...

 

That answer surprises me.  It is a key piece to establish ASAP.  Keeps us in
a known state, without wasting each other's time on "what's wrong?", raises
quality.  Plus, can run code coverage tools to ensure we are very high.
(otherwise, it's more of the same - low coverage, no known and published
state).

I've done new projects enough to know retrofitting into an automated build
and quality infrastructure has a lot more pain than when starting with it in
place.

 

 

  - perhaps my employer will lend us some server space & time for this...
would you like me to check?

 

It would be perfect, but if he wants something back we should discuss the
request with the community ;-)

 

Nothing  - it would be free.  I would set it up and we'd all have access.
I'll "volunteer" and check.  I don't know of a current alternative option.

 

 

 - need a nightly build that:
  - builds & deploys snapshot
  - generates & deploys Maven site

 

I think we do not strictly require this to start but I agree we should have
something on this topic

 

Just have the CI server do it when its ready.

 

 

    - add "3.0" link from 2.x main page to 3.0 main page

 

I think we should delay this after we have cleared ourselve the idea beyond
the 3.0, otherwise we would have nothing to write on that page :-)

 

It would be the Maven site gen results and docs we create as we go.  It will
continue to evolve.  Start with the generated contents from reports.

 

 

 - it's past time to use Sonatype's OSS artifact hosting

 

What do you mean?

 

Hosting the snapshot & release repos there (see previous email discussions;
you mentioned looking into it further); release repo automatically synced to
central.

 

 

However, I'd first like to see the current trunk/2.4.8 released.

 

I was away from the project for a couple of months but I thought you had
everything you need and all the information to perform a release on your
own... does the trunk need something particular I can help with?

 

You said you want to do all the releases (see previous email discussions).
Plus I would need shell access to deploy the site.

 

 

-----Original Message-----
From: Roberto Lo Giacco [mailto:rlo...@gm...]
Sent: Monday, August 30, 2010 4:43 AM
To: dbUnit Developers List
Subject: [dbunit-developer] Next step

Hello all,

this is my second or third call to move the project toward the next
step, but this time I've some time to spend on the project as I
quitted my previous job and I'm now looking for some other
opportunity. I can spend this "forced vacancies" on the project but I
wish to have both your moral and concrete support and I do not want to
operate without you as I know the effort required to reach the target
will be more than I can provide.

The idea is to bring dbunit to the 3.0 generation. What's in my mind
is a complete rewriting of the codebase with massive cleanup.

A lot of code in dbunit is actually a replica of something other
libraries provide in a cleaner and more reliable manner: we have a
minimal internal xml, excel and csv writers/parsers, we have a complex
internal exception management, we are stuck to Java 1.4 support and we
miss Java 5 support for annotations and generics.

What I suggest is to maintain the principles and major design of the
framework while improving and refreshing it. I would like to start
collecting the ideas posted on the tracker and drawing some class
diagrams of the actual codebase. I've already prepared the latter, I
would like some help on the former.

The first thing I wish to discuss is the option to open the library to
other data sources other than relational databases, like LDAP or
object databases. I remind someone asked for such feature and I think
we can achieve such target with an additional level of indirection
which should be decided in the first stage.

If we decide to support such different data sources I think we should
rename Table to something not strictly related to rdbms, may be
Structure could be an option, and Database (DatabaseTester,
DatabaseTestCase, etc...) with Data (DataTester, DataTestCase, etc...)
while other names can stay untouched, like Operation,
OperationListener and DataSet.

I think it would be a waste of time to go further in describing the
idea if it's not shared by you and you can't/wan't support it so
please, post your answers and comments.

Roberto Lo Giacco

----------------------------------------------------------------------------
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
dbunit-developer mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbunit-developer


----------------------------------------------------------------------------
--
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
dbunit-developer mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbunit-developer

 

Re: [dbunit-developer] Next step

[John H. <joh...@gm...>]

I agree with this (in general). I was going to write something along the
same lines:

1) DbUnit 3.0 should be more modular, so that dependencies can be specific
to modules. The Oracle one is a good example.

2) I think we should overhaul how the DataTypeFactory is set -- make it
automatic if possible. It trips up a lot of people to have to set that
property, we see it in the mailing list quite often. (I get tripped up
myself!)

I will have a look over the code to see whether it would be reasonable for
DbUnit to determine the correct DataTypeFactory automatically.

Regards

John Hurst

On Tue, Aug 31, 2010 at 11:21 AM, Zdeněk Vráblík <zd...@vr...> wrote:

> Hi Roberto,
>
> One of the questions for 3.0 should be how to manage dependencies.
>
> There was discussion about oracle jdbc dependency. DbUnit project
> depends on oracle jdbc. I think putting all dependencies into one
> project will not be sustainable if more dependencies will be
> introduced.
>
> I am not sure if I am able to describe in details, but I try.
>
> My suggestion:
> The DbUnit should break into multiple jar files.
> DbUnit kernel would be responsible for searching data types in class
> path. This should avoid ClassNotFound exceptions for dbunit users
> without any interest of using particular advanced functionality.
> DataTypes would dynamically build data type factory according
> available data types and database version. DbUnit user has to define
> just database name and version which is used. This would avaoid
> multiple Factories classes
>
> Each advanced data type would declare which database and from which
> version is supported.
>
> Regards,
> Zdenek
>
> On Mon, Aug 30, 2010 at 10:42 AM, Roberto Lo Giacco <rlo...@gm...>
> wrote:
> > Hello all,
> >
> > this is my second or third call to move the project toward the next
> > step, but this time I've some time to spend on the project as I
> > quitted my previous job and I'm now looking for some other
> > opportunity. I can spend this "forced vacancies" on the project but I
> > wish to have both your moral and concrete support and I do not want to
> > operate without you as I know the effort required to reach the target
> > will be more than I can provide.
> >
> > The idea is to bring dbunit to the 3.0 generation. What's in my mind
> > is a complete rewriting of the codebase with massive cleanup.
> >
> > A lot of code in dbunit is actually a replica of something other
> > libraries provide in a cleaner and more reliable manner: we have a
> > minimal internal xml, excel and csv writers/parsers, we have a complex
> > internal exception management, we are stuck to Java 1.4 support and we
> > miss Java 5 support for annotations and generics.
> >
> > What I suggest is to maintain the principles and major design of the
> > framework while improving and refreshing it. I would like to start
> > collecting the ideas posted on the tracker and drawing some class
> > diagrams of the actual codebase. I've already prepared the latter, I
> > would like some help on the former.
> >
> > The first thing I wish to discuss is the option to open the library to
> > other data sources other than relational databases, like LDAP or
> > object databases. I remind someone asked for such feature and I think
> > we can achieve such target with an additional level of indirection
> > which should be decided in the first stage.
> >
> > If we decide to support such different data sources I think we should
> > rename Table to something not strictly related to rdbms, may be
> > Structure could be an option, and Database (DatabaseTester,
> > DatabaseTestCase, etc...) with Data (DataTester, DataTestCase, etc...)
> > while other names can stay untouched, like Operation,
> > OperationListener and DataSet.
> >
> > I think it would be a waste of time to go further in describing the
> > idea if it's not shared by you and you can't/wan't support it so
> > please, post your answers and comments.
> >
> > Roberto Lo Giacco
> >
> >
> ------------------------------------------------------------------------------
> > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> > Be part of this innovative community and reach millions of netbook users
> > worldwide. Take advantage of special opportunities to increase revenue
> and
> > speed time-to-market. Join now, and jumpstart your future.
> > http://p.sf.net/sfu/intel-atom-d2d
> > _______________________________________________
> > dbunit-developer mailing list
> > dbu...@li...
> > https://lists.sourceforge.net/lists/listinfo/dbunit-developer
> >
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>



-- 
Life is interfering with my game

Re: [dbunit-developer] Next step

[Zdeněk V. <zd...@vr...>]

Hi Roberto,

One of the questions for 3.0 should be how to manage dependencies.

There was discussion about oracle jdbc dependency. DbUnit project
depends on oracle jdbc. I think putting all dependencies into one
project will not be sustainable if more dependencies will be
introduced.

I am not sure if I am able to describe in details, but I try.

My suggestion:
The DbUnit should break into multiple jar files.
DbUnit kernel would be responsible for searching data types in class
path. This should avoid ClassNotFound exceptions for dbunit users
without any interest of using particular advanced functionality.
DataTypes would dynamically build data type factory according
available data types and database version. DbUnit user has to define
just database name and version which is used. This would avaoid
multiple Factories classes

Each advanced data type would declare which database and from which
version is supported.

Regards,
Zdenek

On Mon, Aug 30, 2010 at 10:42 AM, Roberto Lo Giacco <rlo...@gm...> wrote:
> Hello all,
>
> this is my second or third call to move the project toward the next
> step, but this time I've some time to spend on the project as I
> quitted my previous job and I'm now looking for some other
> opportunity. I can spend this "forced vacancies" on the project but I
> wish to have both your moral and concrete support and I do not want to
> operate without you as I know the effort required to reach the target
> will be more than I can provide.
>
> The idea is to bring dbunit to the 3.0 generation. What's in my mind
> is a complete rewriting of the codebase with massive cleanup.
>
> A lot of code in dbunit is actually a replica of something other
> libraries provide in a cleaner and more reliable manner: we have a
> minimal internal xml, excel and csv writers/parsers, we have a complex
> internal exception management, we are stuck to Java 1.4 support and we
> miss Java 5 support for annotations and generics.
>
> What I suggest is to maintain the principles and major design of the
> framework while improving and refreshing it. I would like to start
> collecting the ideas posted on the tracker and drawing some class
> diagrams of the actual codebase. I've already prepared the latter, I
> would like some help on the former.
>
> The first thing I wish to discuss is the option to open the library to
> other data sources other than relational databases, like LDAP or
> object databases. I remind someone asked for such feature and I think
> we can achieve such target with an additional level of indirection
> which should be decided in the first stage.
>
> If we decide to support such different data sources I think we should
> rename Table to something not strictly related to rdbms, may be
> Structure could be an option, and Database (DatabaseTester,
> DatabaseTestCase, etc...) with Data (DataTester, DataTestCase, etc...)
> while other names can stay untouched, like Operation,
> OperationListener and DataSet.
>
> I think it would be a waste of time to go further in describing the
> idea if it's not shared by you and you can't/wan't support it so
> please, post your answers and comments.
>
> Roberto Lo Giacco
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>

[dbunit-developer] DbUnit 3.0: Table/Structure

[John H. <joh...@gm...>]

I've also been curious about whether DbUnit could support alternative data
sources. (It would be nice to rename Database to DataSource, but that term
already has a widely-accepted meaning in Java.)

Another area for consideration of this is the NoSQL databases -- now all the
rage.

But it seems to me that DbUnit is very much about tabular data. You would
like to rename ITable? But consider the methods:
  ITableMetaData getTableMetaData()
  int getRowCount()
  Object getValue(int row, String column)

And ITableMetaData:
  String getTableName()
  Column[] getColumns()
  Column[] getPrimaryKeys()
  int getColumnIndex(String columnName)

These are very much about tables. I would be interested to hear whether you
think these interfaces would apply well to LDAP (or a NoSQL database).

To me, a major challenge for DbUnit is optimizing the representation of
tabular test data. XML for example, the de-facto standard DbUnit input
format, is notoriously bad for representing tabular data. CSV is much
better, but has its own limitations. Most of my work with DbUnit has been to
make tabular test data more concise and readable, to make tests clearer and
easier to write. It's a usability issue, rather than one of flexibility.

Regards

John Hurst

-- 
Life is interfering with my game

[dbunit-developer] DbUnit 3.0: Dependencies

[John H. <joh...@gm...>]

I agree with the idea of using 3rd party libraries instead of reinventing
things (possibly badly) within DbUnit.

However, we should try to keep our dependencies well-managed and minimal at
the same time!

Spring is an example of a project that has pretty well-managed dependencies.
The only global dependency in Spring is commons-logging. Various modules
depend on other libraries.

Another library we use where I work is Tapestry, which is kind of an example
of the opposite extreme. Tapestry imports just about the whole world in
dependencies (I'm exaggerating a little). It can cause problem with
versions.

In DbUnit, we've hit dependency version problems at least once that I'm
aware of. The dependency on Apache POI is fixed to a certain version, and
because of breaking changes in POI we break if someone tries to use a
different version.

Another issue with 3rd party libraries is how they manage their releases.
For example, Google provides some very nice libraries such as their
Collections library (now in Guava). But they are pretty slack about release
management. From what I understand, they don't release artifacts to Maven
Central, and also they don't necessarily tag their releases. So one might
approach Google libraries with some caution.

Just some thoughts.

John Hurst

-- 
Life is interfering with my game

[dbunit-developer] DbUnit 3.0 - Infrastructure (Wiki, CI, VCS)

[John H. <joh...@gm...>]

My thoughts:

Wiki.

It would be great to get a really decent Wiki. The current one is a bit
hokey. I wonder if we could get a Confluence instance somehow? That's my
preferred wiki, although any suitably "rich" wiki would be OK.

I'm pretty keen on working on samples and documentation. I wrote a chapter
on DbUnit for the "Java Power Tools" book a couple of years ago. More
recently I've been working on some DbUnit samples (among other things) based
on the Eclipse BIRT sample database, which is a rather nice little database
for that kind of thing.

Some questions that come up a lot could be better answered by reference to a
standard set of samples. For example, dealing with auto-generated keys. (I
myself haven't actually dealt with that problem, being an Oracle/PostgreSQL
guy mostly. But I would like to learn how to deal with it, and create some
nice samples showing it.)

Continuous Integration/Testing

I feel bad for not following through with the CI work I started on. I still
would like to try to get some CI going on Amazon EC2, but this is more for
my own interest, and I'm not sure it is appropriate for the project
long-term. Some dedicated server space would probably be better. It is
tricky (from my perspective) to include support for testing on Windows
(SQL-Server). Probably all of the other databases can be set up on a single
Linux server for testing purposes.

It's interesting though to consider how many different versions of databases
to support in DbUnit integration testing. Most projects don't have this
problem, but for DbUnit it is very relevant. For example, there is every
reason to expect different behavior for datatypes (e.g. CLOBs) on Oracle
versions 9, 10 and 11.

It's also interesting to consider whether there are licensing issues. I have
always believed that the OTN license for Oracle permitted unlimited use for
development purposes. A couple of weeks ago I had a big argument on the
subject with an Oracle marketing rep, who was trying to squeeze more money
out of our company. He said that the OTN was time-limited, only meant for
resellers, etc etc. I gave up on him as just being a marketing jerk. But it
is a bit of an issue for the commercial databases.

Version Control

Finally, VCS. I've come to believe that distributed systems, such as Git,
are considerably more suitable for open-source projects than Subversion.
Don't get me wrong: unlike many Git users, I'm still a Subversion fan. (We
use it where I work and are very happy with it.) But I've found that Git is
much better for open-source work. For example, a non-committer can check out
a clone and work on a private branch very conveniently. Using GitHub, it's
possible to contribute elaborate patches back to the main code base in a
powerful way.

If others feel similarly about DVCS, perhaps we should move the code base to
Git. GitHub also offers a pretty nice Wiki facility. However, it seems
SourceForge also supports Git.

I understand that Roberto would like to move this phase of the project ahead
*very* quickly. (One week of discussion, two weeks of coding.) I don't want
to slow this process down with extraneous worries about infrastructure.

Just my thoughts.

John Hurst

-- 
Life is interfering with my game

Re: [dbunit-developer] Next step

[John H. <joh...@gm...>]

Hello,

Great news. I'm very excited. (But also very busy. :-()

I have comments on several aspects of this proposal. I will put them in
separate emails to make it easier to follow the threads.

Regards

John Hurst

On Tue, Aug 31, 2010 at 6:17 AM, Roberto Lo Giacco <rlo...@gm...>wrote:

> Hi Jeff, first one to answer, I hope others will follow.
> About your questions...
>
> On Mon, Aug 30, 2010 at 14:30, Jeff Jensen <jj...@ap...> wrote:
>
>> What are your process proposals to do this?
>>
>
> If you mean what procedure I suggest to move on the next step is the common
> one:
>
>    - a maximum one week discussion during while we draw the baselines and
>    start code some usage example
>    - a maximum coding effort of about two weeks to have the first alfa
>    release to share among developers and have feedbacks about the design
>    - refactor what's necessary and move to beta stage with a release for
>    power users
>
> I first think of proper infrastructure to help with development success and
>> users getting info & easily trying it:
>>
>
> I perfectly understand your point but I currently do not have any server
> resource available as I quitted my job.  I would add an integration test
> machine (as already said many times on this list). I think we should not ask
> too much unless we already have a solution....
>
>  - where to house the docu notes you speak of?  SF wiki?
>>
>
> Unless we have any other resource already available....
>
>  - need a CI setup; where/how can we do this?
>>
>
> I think we can start without CI and in the meanwhile someone should
> volunteer to find one: we should write a bunch of working classes and test
> before CI having any sense...
>
>
>>   - perhaps my employer will lend us some server space & time for this...
>> would you like me to check?
>>
>
> It would be perfect, but if he wants something back we should discuss the
> request with the community ;-)
>
>
>>  - need a nightly build that:
>>   - builds & deploys snapshot
>>   - generates & deploys Maven site
>>
>
> I think we do not strictly require this to start but I agree we should have
> something on this topic
>
>
>>     - add "3.0" link from 2.x main page to 3.0 main page
>>
>
> I think we should delay this after we have cleared ourselve the idea beyond
> the 3.0, otherwise we would have nothing to write on that page :-)
>
>
>>  - it's past time to use Sonatype's OSS artifact hosting
>>
>
> What do you mean?
>
>
>> However, I'd first like to see the current trunk/2.4.8 released.
>>
>
> I was away from the project for a couple of months but I thought you had
> everything you need and all the information to perform a release on your
> own... does the trunk need something particular I can help with?
>
>
>
>> -----Original Message-----
>> From: Roberto Lo Giacco [mailto:rlo...@gm...]
>> Sent: Monday, August 30, 2010 4:43 AM
>> To: dbUnit Developers List
>> Subject: [dbunit-developer] Next step
>>
>> Hello all,
>>
>> this is my second or third call to move the project toward the next
>> step, but this time I've some time to spend on the project as I
>> quitted my previous job and I'm now looking for some other
>> opportunity. I can spend this "forced vacancies" on the project but I
>> wish to have both your moral and concrete support and I do not want to
>> operate without you as I know the effort required to reach the target
>> will be more than I can provide.
>>
>> The idea is to bring dbunit to the 3.0 generation. What's in my mind
>> is a complete rewriting of the codebase with massive cleanup.
>>
>> A lot of code in dbunit is actually a replica of something other
>> libraries provide in a cleaner and more reliable manner: we have a
>> minimal internal xml, excel and csv writers/parsers, we have a complex
>> internal exception management, we are stuck to Java 1.4 support and we
>> miss Java 5 support for annotations and generics.
>>
>> What I suggest is to maintain the principles and major design of the
>> framework while improving and refreshing it. I would like to start
>> collecting the ideas posted on the tracker and drawing some class
>> diagrams of the actual codebase. I've already prepared the latter, I
>> would like some help on the former.
>>
>> The first thing I wish to discuss is the option to open the library to
>> other data sources other than relational databases, like LDAP or
>> object databases. I remind someone asked for such feature and I think
>> we can achieve such target with an additional level of indirection
>> which should be decided in the first stage.
>>
>> If we decide to support such different data sources I think we should
>> rename Table to something not strictly related to rdbms, may be
>> Structure could be an option, and Database (DatabaseTester,
>> DatabaseTestCase, etc...) with Data (DataTester, DataTestCase, etc...)
>> while other names can stay untouched, like Operation,
>> OperationListener and DataSet.
>>
>> I think it would be a waste of time to go further in describing the
>> idea if it's not shared by you and you can't/wan't support it so
>> please, post your answers and comments.
>>
>> Roberto Lo Giacco
>>
>>
>> ----------------------------------------------------------------------------
>> --
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> dbunit-developer mailing list
>> dbu...@li...
>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> dbunit-developer mailing list
>> dbu...@li...
>> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>


-- 
Life is interfering with my game

Re: [dbunit-developer] Next step

[Roberto Lo G. <rlo...@gm...>]

Hi Jeff, first one to answer, I hope others will follow.
About your questions...

On Mon, Aug 30, 2010 at 14:30, Jeff Jensen <jj...@ap...> wrote:

> What are your process proposals to do this?
>

If you mean what procedure I suggest to move on the next step is the common
one:

   - a maximum one week discussion during while we draw the baselines and
   start code some usage example
   - a maximum coding effort of about two weeks to have the first alfa
   release to share among developers and have feedbacks about the design
   - refactor what's necessary and move to beta stage with a release for
   power users

I first think of proper infrastructure to help with development success and
> users getting info & easily trying it:
>

I perfectly understand your point but I currently do not have any server
resource available as I quitted my job.  I would add an integration test
machine (as already said many times on this list). I think we should not ask
too much unless we already have a solution....

 - where to house the docu notes you speak of?  SF wiki?
>

Unless we have any other resource already available....

 - need a CI setup; where/how can we do this?
>

I think we can start without CI and in the meanwhile someone should
volunteer to find one: we should write a bunch of working classes and test
before CI having any sense...


>   - perhaps my employer will lend us some server space & time for this...
> would you like me to check?
>

It would be perfect, but if he wants something back we should discuss the
request with the community ;-)


>  - need a nightly build that:
>   - builds & deploys snapshot
>   - generates & deploys Maven site
>

I think we do not strictly require this to start but I agree we should have
something on this topic


>     - add "3.0" link from 2.x main page to 3.0 main page
>

I think we should delay this after we have cleared ourselve the idea beyond
the 3.0, otherwise we would have nothing to write on that page :-)


>  - it's past time to use Sonatype's OSS artifact hosting
>

What do you mean?


> However, I'd first like to see the current trunk/2.4.8 released.
>

I was away from the project for a couple of months but I thought you had
everything you need and all the information to perform a release on your
own... does the trunk need something particular I can help with?



> -----Original Message-----
> From: Roberto Lo Giacco [mailto:rlo...@gm...]
> Sent: Monday, August 30, 2010 4:43 AM
> To: dbUnit Developers List
> Subject: [dbunit-developer] Next step
>
> Hello all,
>
> this is my second or third call to move the project toward the next
> step, but this time I've some time to spend on the project as I
> quitted my previous job and I'm now looking for some other
> opportunity. I can spend this "forced vacancies" on the project but I
> wish to have both your moral and concrete support and I do not want to
> operate without you as I know the effort required to reach the target
> will be more than I can provide.
>
> The idea is to bring dbunit to the 3.0 generation. What's in my mind
> is a complete rewriting of the codebase with massive cleanup.
>
> A lot of code in dbunit is actually a replica of something other
> libraries provide in a cleaner and more reliable manner: we have a
> minimal internal xml, excel and csv writers/parsers, we have a complex
> internal exception management, we are stuck to Java 1.4 support and we
> miss Java 5 support for annotations and generics.
>
> What I suggest is to maintain the principles and major design of the
> framework while improving and refreshing it. I would like to start
> collecting the ideas posted on the tracker and drawing some class
> diagrams of the actual codebase. I've already prepared the latter, I
> would like some help on the former.
>
> The first thing I wish to discuss is the option to open the library to
> other data sources other than relational databases, like LDAP or
> object databases. I remind someone asked for such feature and I think
> we can achieve such target with an additional level of indirection
> which should be decided in the first stage.
>
> If we decide to support such different data sources I think we should
> rename Table to something not strictly related to rdbms, may be
> Structure could be an option, and Database (DatabaseTester,
> DatabaseTestCase, etc...) with Data (DataTester, DataTestCase, etc...)
> while other names can stay untouched, like Operation,
> OperationListener and DataSet.
>
> I think it would be a waste of time to go further in describing the
> idea if it's not shared by you and you can't/wan't support it so
> please, post your answers and comments.
>
> Roberto Lo Giacco
>
>
> ----------------------------------------------------------------------------
> --
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> dbunit-developer mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbunit-developer
>