I would like to take the time to discuss the post release issues
we have in CVS since we are post Final Release for Framework. LogKit
has one more iteration, and Excalibur has two more at least.
For everyone's convenience I pasted the contents of the file below.
----------------------------------------------------------------------
Avalon 4.0 Post Release Issues
------------------------------
The purpose for this file is to document potential issues
that we need to discuss after the Avalon 4.0 Final Release,
and before any maintenance releases (i.e. 4.1, 4.0.1, etc.).
Since I don't want to clutter the mailing list and cause alarm
unnecessarily, I am placing the issues in this list.
Please use this file to relay any issues that we need to
address after release.
Issues:
-------
* Should we require every Excalibur component to have a package.html
file with instructions on how to use the components? This
should be settled on for Beta 2.
Berin: I think this is a good design goal, and we should do it before
final release.
* Should we consider using JUnit for the unit tests instead of
Testlet? It would mean less code for us to maintain and
document. JUnit has a critical mass surrounding it, and
documentation--whereas I don't understand Testlet, and the
only way to do so is to go through the source code.
Berin: Testlet has more documentation, pretty graphical displays
and such. It might be better to go with a defacto standard
as opposed to maintaining our own. If we decide to keep
Testlet, we have to have some definite plans beyond what
is currently available. The conversion between Testlet and
JUnit is not that difficult (we don't even have to change
the names of the methods). I just don't want to have to
maintain a project if there is another one that fits the
same bill--and is actively supported by its own community.
* What kind of release schedule do we want? Should be make
regular releases every 3 months with what we have (i.e.
bug fixes or new features)? Or Should we be milestone
driven? For Framework/Excalibur I would lean toward the
regular release approach.
Berin: Framework might be better on point releases as new features
are available. I don't forsee Framework changing much at all.
Excalibur will have new features and bug fixes constantly being
added, so a regular release cycle will benefit that project.
LogKit is also actively maintained. I would like to keep that
on a regular release cycle as well--that way we can phase out
the deprecated stuff over at least two releases. If we are
on a 3 month release cycle, that means we will only have to
maintain the deprecated functions for six months, giving plenty
of time for developers to migrate to the correct use.
* How do components in Scratchpad be promoted to Excalibur?
In other words, what are the exit criteria?
Berin: The exit criteria should be that the Components conform to the
Avalon idioms outlined in the "Programming with Avalon" document,
have a stable API, and pass a vote. If the API is planned to
change before release then it is not up for vote. If the new
packages contain Components, then they must conform to documented
standards or it will not be up for vote. Once it passes those
criteria, we need to have a vote of at least threee +1 votes and
no -1 votes.
* Should we update to use Velocity rather than Stylebook
- Considering the recent move to Cocoon/DocBook, I would
be -1 on Velocity. Although, Cocoon can use velocity. (BL)
- Sounds good to me (PD)
Berin: It sounds like this might be resolved. Cocoon does allow for
more flexibility.
* Should we wait for commons to build component directory
or do it ourselves?
- Excalibur is our "component directory" (BL)
- Excalibur is our project that contains components (ie
component repository) but we don't have a nice easily integratable
interface lookup/discover and download components separately. (ie
think combination of RpmFind, CPAN and tucows) (PD)
Berin: I am all for a Component Directory, but we also have to think
of hosting. Once I get my site set up (www.d-haven.org) I can
donate resources for the Component Directory. I would be +1
for creating it ourselves--as we know how we intend to use
it better.
* should we write our own doclet to better integrate documentation
of distributed src files.
Berin: I am +0. If someone wants to take this on, then by all means
do so.
* Should we support download of resources via JNLP/CJAN/JJAN
Berin: Isn't this what our Component Directory will be? Anyway, we
need some links to discuss this intelligently.
* Should we even store the avalon generated jars (testlet/
logkit/avalon-*/phoenix-* in CVS or should we suck them between projects
automagically).
- This makes it tough to focus on one project at a time. (BL)
- If we have JNLP/CJAN/JJAN repository, that can handle this
requirement. (BL)
Berin: Until we have a Component Directory/JNLP/CJAN/JJAN we can use
the build scripts to handle the automatic pulling of the jars.
* Should we have a CVS check that reformats code on insert into repository.
Berin: I would be +1, except that this will affect the performance of
checkins. Worse, it could cause erroneous changes to be reported.
I think we should test this first. My concern may only apply to
the first time something is checked in after being formatted.
* Should we move to docbook DTD
- I am +1. The docbook documentation build process is done, and we have
an easy migration path. DocBook affords a better semantic view of the
documentation plus more tools to create alternate formats. (BL)
- +1 (PD)
Berin: We have two +1, all we need is one more. We should generate the
DocBook of all the existing pages and get rid of the stylebook
references.
* Should we move stylebook sheets into jakarta-site CVS
Berin: I am unclear as to this benefit. It may increase maintenance issues
* Enhance Parameters so that it can be built from writer/inputstream in such a
way that it reads in velocity/turbine style parameters
- Perhaps we should have a group of Parameter Builder objects so that the
original form (XML, Configurations, Velocity paramters) can be separated
from the actual Parameters object (SoC). (BL)
- The velocity team moved it to commons and renamed the class
ExtendedProperties so we can probably use our already existing fromProperties()
method.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
