Stephen McConnell wrote:
Carsten Ziegeler wrote:
As soon as they are integrated we can make a release of
sourceresolve but not any sooner because than we would have
to deal with incompatible interface changes.
Quick glance at the dependency graph:
sourceresolve dependes on framework 4.1.3 and pool 1.1
pool 1.1 depends on framework 4.X and excalibur collections 1.0
excalibur collections is depricated if favout of commons collections
It would seem to make sense that we update pool to use common
collections, bump pool to 1.2, and validate sourceresolve against
pool 1.2.
+1
A less quick glance at the documentation:
Tracking down examples of sourcerolve usage is a PITA. The
current documetation basically points you to Cocoon. If you
look around you can find usage in Fortress - but even then,
its somewhat obscure. I think it would much better if the
documentation included some code examples - setting up a
source resolver, adding protocol support, resolving urls,
etc. (including this in the package documentation would be
terrific).
+1
A quick glance at the javadoc:
Running checkstyle on the code as it would generate lots of
messages about missing @param, @return and @exception
declarations. Are you planning on getting these in?
We should strive to have good JavaDocs.
A quick glance at the testcases:
Any plans to get something in place here?
Again, we need something that works.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
