On Wed, 1 Aug 2001 00:23, Berin Loritsch wrote:
> * 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.
+1
> * 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.
+/-0 Indifferent. I like having the control to change things if we need to
(and we will when I integrate my local phoenix tests into CVS). If there is
anything in Junit thats is desired then +0 otherwise -1 (I don't want to
learn anything I don't need).
> * 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.
+1
works for me.
> * 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.
+1
> * 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.
+1
though would it be possible to enhance cocoon so it only generates files that
are needed. Also could we make it fail hard on error - I almost uploaded a
bunch of pages with stack traces in them ;)
> * 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.
Sounds good to me. It is low on my list of priorities though ;)
> * 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.
+0 me too. I have a XMLDoclet similar to the one in cocoon1/alexandria
project except it generates a single XML fragment/document per class. So if
anyone wants to use that and write XSLT sheets for it .... ;)
> * 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.
hmm theres no links available directly. There has been a lot of discussion of
this on ant-dev and commons-dev mailing lists. There is also
jakarta-commons-sandbox/jjan and jakarta-commons-sandbox/cjan prototypes but
they seemed to have died. Geir had some great ideas (also wrote jjan) so
poking him may be of benefit ;)
> * 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.
ok.
> * 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.
Yep. Besides I HATE writing perl scripts ;) Performance hit wouldn't be too
much of a problem as it would only be on commits. After the first round where
every file was touched there would be no false changes reported. That said I
don't have time or energy to do it atm ;)
> * 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.
+1 ;)
> * Should we move stylebook sheets into jakarta-site CVS
>
> Berin: I am unclear as to this benefit. It may increase maintenance
> issues
Mainly it was to help other projects who were using it (like cactus). They
have since modified the sheets again so I don't think it is worth our effort.
Also I think Craig added in XSLT sheets a few days ago .. but I think they
are limited to vanilla document transformations (not changes or spec or
anything else).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
