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]
