Sylvain Wallez wrote:
Stephen McConnell wrote:
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).
Agreed.
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 !
Setting up a simple tesdt case should not be difficult.
I can help to put in place some very basic - but I'll need assistance when it comes down to using the package because I don't know anything about it (but I'm interested all the same).
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) ?
There were references to excalibur-pool-1.1 in the properties and build file. I checked the sources and you correct - the dependency isn't real. I've already updated and committed the respective files so your now only dependent on framework 4.1.3.
Cheers, Steve.
SylvainCarsten Ziegeler wrote:Stephen McConnell wrote:
I would like to propose that we put some priorities in place.
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.
As I mentioned last week, there will be some changes in the
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.
-- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
