sebb wrote:
On 17/06/2009, Filip Hanik - Dev Lists <devli...@hanik.com> wrote:
sebb wrote:

On 16/06/2009, Filip Hanik - Dev Lists <devli...@hanik.com> wrote:


Sebb, I can't find anything that is broken. All your concerns seem
invalid
to me.


Please revisit, especially the NOTICE files.


 no need

The NOTICE file included in the file apache-tomcat-jdbc-1.0.4.zip is
wrong, as I keep trying to point out.
in what way? the date? Notice that the release contains tomcat-juli.jar which in its project notice file, has the date back to 1999

Filip
 Filip

 sebb wrote:



On 15/06/2009, Filip Hanik - Dev Lists <devli...@hanik.com> wrote:




Cleaned up and fixed.

 The release is located here:
 http://people.apache.org/~fhanik/jdbc-pool/v1.0.4/




NOTICE file is incorrect, it should read:

 Apache Tomcat JDBC Pool
Copyright 2008-2009 The Apache Software Foundation

This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).
<<<

[e.g. See


http://www.apache.org/dev/release.html#notice-required]


This assumes that JDBC Pool was first released in 2008; if not adjust
accordingly.




 that date is correct. The code started in 2008


So why does the NOTICE file say this?

<quote>
Copyright 1999-2009 The Apache Software Foundation
</quote>

It is also missing the following required paragraph:

This product includes software developed by
The Apache Software Foundation (http://www.apache.org/).


 cause other files, in the SVN tree may come from earlier times.

OK, but you said it dated from 2008.

Two java files (ResultSet and TestException) don't have AL headers.




 These don't ship with the release


Nevertheless, they need AL headers.


 Has nothing to do with the release itself, hence you can't say the release
is broken.

The jar files don't have NOTICE or LICENSE files.




 Same as Tomcat, only .tar.gz and .zip have it.


Two wrongs don't make a right.


 You still don't get it. NOTICE and LICENSE are for the release. the .jar
file themselves don't constitute the release, only the entire package does.
you may want to verify this with folks who know :)
Releases must consist of a source archive; binary archives are
optional.
The source archive must contain all the items needed to build and test
the binary archive, see:




http://www.apache.org/dev/release.html#what-must-every-release-contain
Therefore the source archive needs to contain the test code.




 no they don't.
 "test" in this case may as well be "try it out", ie, test the code
itself,
not run the test suite. We never ship our test suites.


Again, as others have pointed out, this is not the practice elsewhere
in ASF projects.


 still not a valid concern.

It's not essential, but it's helpful if the jar MANIFEST.MF files
contain the following:

Built-By:
Implementation-Title:
Implementation-Vendor: The Apache Software Foundation
Implementation-Vendor-Id: org.apache
Implementation-Version:
Specification-Title:
Specification-Vendor: The Apache Software Foundation
Specification-Version:

X-Compile-Target-JDK:
X-Compile-Source-JDK:

It might be useful to include the Javadoc in the binary archive.

The build.xml defines compile.source=1.5, however some of the classes
require 1.6, for example SlowQueryReport uses the generic form of
OpenType which was only introduced in 1.6.




 not part of the release


 It's in the archives you published.

E.g. in  apache-tomcat-jdbc-1.0.4.zip/tomcat-jdbc-src.jar


 build.xml, which is your complaint is not part of the release.

The build file relies on the following files for testing, however
there is no indication where these are to be obtained:

c3p0-0.9.1.2.jar
mysql-connector-java-5.0.7-bin.jar




 not part of the release.


The build file is a required part of the release.


 no its not. documentation shows how to build it.

So is the code supposed to be compatible with 1.5 or with 1.6?

The test file DefaultTestCase does not define any test cases, so it
would help some IDEs if it were marked abstract.




 not part of the release



The ResultSet and Statement test classes in the test driver directory
won't compile when using Eclipse, because Eclipse generates an error
for @Override tags applied to methods only defined in interfaces. It's
not clear whether this is an Eclipse bug or a Sun Java bug, but it
does not really add much to use @Override for interface methods, so
perhaps these tags could be removed.




 not part of the release



 <ballot>
 [ ] STABLE - I couldn't find any bugs
 [ ] BETA   - I found some bugs but not critical
 [X] BROKEN - I found some show stoppers




Incorrect NOTICE file, missing N&L files
Incorrect packging.





 </ballot>

 Any comments ?




See above.





 Thanks,
 Filip





---------------------------------------------------------------------
 To unsubscribe, e-mail:


dev-unsubscr...@tomcat.apache.org


 For additional commands, e-mail: dev-h...@tomcat.apache.org






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






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




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




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



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




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

Reply via email to