Let me give some details, since I'm currently working on sourceresolve after some discussion with Carsten. We want to reach API stability on this, because it's used in many places in Cocoon and a such is required if we want to start releasing Cocoon 2.1 (we're not even alpha yet).
To answer your questions, the plan is to start by refining and stabilizing the API and document it, and test into Cocoon 2.1. There's no problem if we start by testing with Cocoon before writing automated unit tests because of the unreleased nature of the 2.1 branch.
Detailed docs and automated unit tests will be written in a second phase, and any help in this area is more than welcome !
Also, I don't see a dependency of sourceresolve on pool. Where did you find it (I'm not fully "fluent" with Avalon build system) ?
Sylvain
Carsten Ziegeler wrote:Stephen McConnell wrote:
I would like to propose that we put some priorities in place.As I mentioned last week, there will be some changes in the
On our release agenda is Avalon framework 4.1.4, logkit 1.2,
excalibur packages: thread 1.1; sourceresolve 1.0;
configuration 1.0; xmlutil 1.0; store 1.0, cornerstone
packages: threads 1.0; connection 1.0; datasources 1.0;
masterstore 1.0; scheduler 1.0; sockets 1.0 threads 1.0.
If we throw into the equation the potential release of
Fortress we also need to address release of the avalon-sandbox
lifecycle package and the instrument package. Phoenix release
is already out but used non-released code - excalibur
configuration, loader and extension.
excalibur sourceresolve package. This includes some minor
interface changes and some more additions.
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.
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).
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?
A quick glance at the testcases:
Any plans to get something in place here?
Cheers, Steve.
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
