Carsten 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.



Carsten

--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




--

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]>

Reply via email to