Message:
The following issue has been closed.
Resolver: James Song
Date: Wed, 6 Oct 2004 2:12 PM
This is fixed.
---------------------------------------------------------------------
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: Closed
Priority: Major
Resolution: FIXED
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: Wed, 6 Oct 2004 2:12 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
