Berin Loritsch wrote:
Stephen McConnell wrote:
Berin Loritsch wrote:
I have put together a suite of components for Phase I.
The location is here:
http://avalon.apache.org/~bloritsch/excalibur-dist/
Let me know what you think.
Excalibur i18n
1. Does not need to be in the list.
Used by Pool. Unless you are saying there has been absolutely no change since it was last released.
Absolutely no change since the last release.
Excalibur Component (ECM)
1. Excalibur component documentation (index.html link to JavaDoc points to the entire Avalon Javadoc - not the local component package javadoc). 2. Excalibur Component index.html describes TestCase and not ECM
Hmm. It is just title changing, or does it really describe TestCase?
Here is the sum total of the ECM documentation (excluding Javadoc).
Introduction
This project contains utilities which can be used to write Excalibur Test Cases.
3. excalibur-component and excalibur-component-complete have identical extension names in their respective manifests (should be changed)
Ok. Do you know how to merge the extensions from all the other manifests automatically?
Yep. What exactly do you have in mind?
Excalibur Instrument
1. Excalibur instrument documentation (index.html link to JavaDoc points to the entire Avalon Javadoc - not the local instrument package javadoc). 2. Content of the link to Insrument Manager needs to be improved.
:) Volunteering?
Not really - I think its better if someone who knows the package gets into this. I do think the at least some basic description of the package is a *requirement* for a realease. Putting out a relase without any descriptive documentation is below my OK threshhold :-)
3. Content of the link to Insrument Client needs to be improved.
Volunteering?
Same note as above.
I'm not trying to dip outy on the work - its simply that I'm not familiar with the package and I'm sure that other people (i.e. the authors) could pull this together ASAP. If this isn't the case then we should reconsider the release process - I'm not interested in supporting something I'm not deeply into that doesn't have basic documentation.
4. How-To links should be removed as they don't contain anything.
Doable.
Excalibur Instrument Manager
1. seperation of instrument manager interfaces from implementation is good however the AltRMI classes should be seperated out into and independent server side AltRMI monitor package that should probably be colocated with the instrument client (i.e. client and server jars for an AltRMI monitoring solution) - see multiple prior emails on this subject.
Just getting this thing out there to start the ball rolling. Feel free to make that change.
Will do.
Excalibur Logger 1.0.1
1. Content of the documentation is all about i18n, not Logger!
Hmm. Alot of these docs were merely "starter pages" or placeholders, so there are copy and paste issues at work. Are you sure it is describing i18n and not just need a fixed title?
From Excalbur Logger index.html:
Introduction Excalibur's Internationalization package is found in org.apache.avalon.excalibur.i18n. Avalon Excalibur includes a method of managing resources, and an interface for specifying the resource. Support for XML resource bundles are still under development.
Excalibur Pool 1.2
1. Content of the documentation is all about i18n, not Pool! 2. Excalibur pool documentation (index.html link to JavaDoc points to the entire Avalon Javadoc - not the local pool package javadoc).
Same comment as above.
From Excalbur Pool index.html:
Introduction Excalibur's Internationalization package is found in org.apache.avalon.excalibur.i18n. Avalon Excalibur includes a method of managing resources, and an interface for specifying the resource. Support for XML resource bundles are still under development.
Excalibur TestCase 1.0
1. The is zero documentation - at least an example should be presented and perhaps a table of the principal classes. 2. Excalibur testcase documentation (index.html link to JavaDoc points to the entire Avalon Javadoc - not the local package javadoc).
This is where we need some helpers with documentation.
I think it was during an investigation ito the thread package that I noticed that the dependency on test case is lmited to BufferedLogger (por something like that). In these cases is seems to me that it would make more sence to seperate out some of the utilities into a non-depdent utility class as opposed to the full test-case dependecy?
Cheers, Steve.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
