Peter Donald wrote:
>
> > * 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).
That's the point. It really doesn't require alot of learning--I converted
the tests for i18n package from JUnit to Testlet--which only forced me to
change the class we extended and the name of one or two methods. All the
tests pretty much functioned as is.
As I mentioned in another thread, the graphical feedback of a red bar is
much easier to catch than trolling through mountains of logs for the ERROR
events--as the debug entries are necessary to figure out what is going on
in case there is an error.
JUnit is open source, so there is nothing that says we can't change things.
> > * 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 ;)
I will pass this to the Cocoon dev list.
> > * 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 ;)
I hear you. It is low on mine as well.
> > * 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 .... ;)
I am of the mind: Why bother? It is additional work for which the current
Doclet serves our needs.
> > * 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 ;)
I know jEdit has a component loading and version checking framework. We may
be able to see if their approach is usable.
> > * 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 ;)
So like the Doclet, this one may die. The question comes though--what about
the JSBeautifier classes from Cocoon or AStyle (C++ executable) to do the formatting
and just a script to kick it off? They are configurable enough for our purposes.
> > * 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).
In that case I am -1.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
