The following issue has been updated:
Updater: Zach Smith (mailto:[EMAIL PROTECTED])
Date: Tue, 5 Oct 2004 2:23 PM
Comment:
i have been having the same problems and actually have been trying to send a
fix to the list with not success...so, i'll attach it here.
Changes:
Attachment changed to webappfix.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/BEEHIVE-5?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/BEEHIVE-5
Here is an overview of the issue:
---------------------------------------------------------------------
Key: BEEHIVE-5
Summary: controls test infrastructure needs rearchitecture
Type: Test
Status: Open
Priority: Major
Project: Beehive
Components:
Controls
Fix Fors:
Version 1
Versions:
Version 1
Assignee: James Song
Reporter: Kenneth Tam
Created: Tue, 5 Oct 2004 2:18 PM
Updated: Tue, 5 Oct 2004 2:23 PM
Description:
The current controls test infrastructure has serious deficiencies.
1) It's next to impossible to get a "clean" sandbox after running tests,
because the infrastructure does a bunch of work "in place" (ie, creating temp
files in dirs that are source controlled).
2) Many controls test source files are duplicated and have 2 copies checked
into svn! Specifically, controls/test/controlsWeb/controls/* and
controls/test/src/* contain massive duplication.
3) controls/test/controlsWeb/controls contains things that aren't controls!
(like drivers!!).
Controls used for tests should be under controls/test/src/controls. Because
using apt to build a complex collection of control files is non-trivial (apt's
limited dep detection means that you'll probably need to make several passes,
explicitly compiling some files before others), you can't rely on a single
generic script like buildWebappCore.xml to properly compile all your controls.
Instead, you should follow the example of the "build-beans" target in
controls/test/build.xml -- it has multiple apt calls with specific filtering
rules so that things like checkers get compiled before the interfaces that use
them, and inner controls get compiled before outers that reference them.
controls/test/src/controls/* is built into a checkinbeans.jar right now
(good!), but it doesn't seem to be used anywhere (bad!!). checkinbeans.jar
should be the mechanism by which controls are made available in the
controlsWeb, via WEB-INF/lib.
The current madness explains wackiness like:
1) if you create a brand-new enlistment and try to run the checkin tests,
they'll fail the first time (the generic build script being used to build
controlsWeb's controls is too simple to do it right).
2) running checkin.tests again usually works because the first pass happened to
leave enough build artifacts around to get past the original errors.
3) Adding new test controls is perilous and unreliable, since the build depends
on compiling files in an arbitrary order and failing at an opportune rather
than inopportune spot.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
