tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: [VOTE] Release JDBC Pool module v1.0.5
Date Fri, 26 Jun 2009 14:36:54 GMT
sebb wrote:
> On 26/06/2009, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
>   
>> sebb wrote:
>>
>>     
>>> On 24/06/2009, Filip Hanik - Dev Lists <devlists@hanik.com> wrote:
>>>
>>>
>>>       
>>>> Cleaned up and fixed.
>>>>
>>>>  The release is located here:
>>>>  http://people.apache.org/~fhanik/jdbc-pool/v1.0.5/
>>>>
>>>>
>>>>         
>>> Exactly the same path names were used previously; I assume you are
>>> referring to the following versions of the files:
>>>
>>>
>>>       
>> apache-tomcat-jdbc-1.0.5-bin.tar.gz.md5:808cf400c4f7f4de7294b844c68108fa
>>     
>> apache-tomcat-jdbc-1.0.5-bin.zip.md5:3f20849d6b0dbe29bb9707cd519c456c
>>     
>> apache-tomcat-jdbc-1.0.5-src.tar.gz.md5:6a63d1e77c47c5d6385cf680dac4514c
>>     
>> apache-tomcat-jdbc-1.0.5-src.zip.md5:7b4870d50e498a18014031589b8a88eb
>>     
>>> rather than the older ones:
>>>
>>>
>>>       
>> apache-tomcat-jdbc-1.0.5-bin.tar.gz.md5:b6081e6d34a8e9ecd70b505c90e73485
>>     
>> apache-tomcat-jdbc-1.0.5-bin.zip.md5:76cb2efd7ce7093d71e4a989e71d2874
>>     
>> apache-tomcat-jdbc-1.0.5-src.tar.gz.md5:d8d08870f3479080582d3261a4d1afe5
>>     
>> apache-tomcat-jdbc-1.0.5-src.zip.md5:cc6992ff33524f15052f9b72588b628f
>>     
>>> ==
>>>
>>> The source and test source archives contain META-INF/MANIFEST.MF files
>>> which don't belong in a source archive.
>>>
>>>
>>>       
>>  these are fine.
>>
>>     
>>> The binary archives contain MD5 hashes of all but one of the jars;
>>> again, these don't belong in the archives.
>>>
>>> The jars should contain NOTICE and LICENSE files.
>>>
>>>
>>>       
>>  no they should not. I think I've told you before, that NOTICE and LICENSE
>> files are for a release, not for individual files within a release.
>>
>>     
>>> There's no easily accessible documentation on how to build and test the
>>>       
>> code.
>>     
>>> If someone is familiar with Ant, they can work out what the targets
>>> do, but the user should not have to do this.
>>>
>>> The ant script automatically downloads jars, some of which don't have
>>> Apache Licenses. In particular, the MySQL licence appears to be GPL,
>>> which is not compatible with the AL.
>>>
>>>
>>>       
>>  yes, I will remove this.
>>
>>     
>>> AFAICT, this is specifically forbidden:
>>>
>>>
>>>       
>> http://www.apache.org/legal/3party.html#options-build-may2
>>     
>>> The "ant test" target generates a few warnings, e.g.
>>>
>>> WARNING: Database connection pool evicter thread interval is set to
>>> lower than 1 second.
>>>
>>> Several of the tests fail.
>>>
>>>
>>>       
>>  I will remove all tests. It was a bad idea to include to begin with, since
>> they are not part of the release either.
>>
>>     
>>> There's no documentation on what database needs to be set up in order
>>> to run the database tests so I don't know if these are due to failure
>>> to set up the database correctly or whether the test failures were
>>> nothing to do with the database.
>>>
>>>
>>>       
>>  that will be solved when the tests go away
>>     
>
> In which case, how can reviewers test the code?
>   
you misunderstand "test the code". When you test a car, do you run unit 
test on the car components? No you drive the car on the road.
Same thing goes on here.
> That is not the solution either.
>
> It should be fairly easy to remove the dependency on MySQL and c3p0 -
> if not, then IMO the tests are too specific, as Tomcat DBCP should
> work with any JDBC provider.
>   
Actually, I can let the build script download MySQL, or change it to 
Derby. Its not forbidden to download something, as long as the user has 
to turn on a flag to do so.

> As an experiment, I tried using Derby instead of MySQL, and most of
> the tests worked. [I'm not yet sure why some tests failed.
> Unfortunately the output gives no clue to me.]
>   
I think its better to use Derby. yes.
> I suggest changing the Ant test classpath to include whatever jars it
> finds in the include directory, and change the test code to pick up
> the database settings from build.properties Then all a tester has to
> do is put their JDBC jar in the directory and set up the database as
> required.
>
>   
>>> Ideally, the user should be given the option of running the JDBC tests
>>> against whatever database they prefer. If the tests require tables etc
>>> to be set up, these should either be done as part of the test setup,
>>> or there should be clear documentation on what data needs to be set
>>> up.
>>>
>>>
>>>
>>>       
>>>>  <ballot>
>>>>  [ ] STABLE - I couldn't find any bugs
>>>>  [ ] BETA   - I found some bugs but not critical
>>>>  [ ] BROKEN - I found some show stoppers
>>>>  </ballot>
>>>>
>>>>  Any comments ?
>>>>
>>>>  Thanks,
>>>>  Filip
>>>>
>>>>
>>>>         
>> ---------------------------------------------------------------------
>>     
>>>>  To unsubscribe, e-mail:
>>>>         
>> dev-unsubscribe@tomcat.apache.org
>>     
>>>>  For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>       
>> ---------------------------------------------------------------------
>>     
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>>
>>>
>>>       
>> ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>  For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message