You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by be...@incubator.apache.org on 2004/10/05 23:18:34 UTC
[jira] Created: (BEEHIVE-5) controls test infrastructure needs rearchitecture
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
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:18 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
[jira] Resolved: (BEEHIVE-5) controls test infrastructure needs rearchitecture
Posted by be...@incubator.apache.org.
Message:
The following issue has been resolved as FIXED.
Resolver: James Song
Date: Wed, 6 Oct 2004 2:11 PM
This is fixed with Zack's code.
---------------------------------------------------------------------
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: Resolved
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:11 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
[jira] Updated: (BEEHIVE-5) controls test infrastructure needs rearchitecture
Posted by be...@incubator.apache.org.
The following issue has been updated:
Updater: Zach Smith (mailto:zsmith@bea.com)
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
[jira] Closed: (BEEHIVE-5) controls test infrastructure needs rearchitecture
Posted by be...@incubator.apache.org.
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