99 lines
3.8 KiB
Plaintext
99 lines
3.8 KiB
Plaintext
This directory contains the Beehive Controls source and test files. This
|
|
README provides an overview of the basic directory structure, and describes
|
|
some of the useful ant targets for building, generating javadoc, and running
|
|
tests for the Controls runtime.
|
|
|
|
SOURCE DIRECTORY STRUCTURE:
|
|
|
|
./src:
|
|
|
|
Contains all of the source files for the Beehive Controls runtime. When the
|
|
runtime is built, all of the generated classes end up in
|
|
build/jars/controls.jar.
|
|
|
|
./src/api:
|
|
|
|
Contains all of the source files for Controls public APIs used by Control
|
|
authors or clients. All annotation type, interfaces, and classes in the public
|
|
API set live within the org.apache.beehive.controls.api.* package space.
|
|
|
|
./src/spi:
|
|
|
|
Contains a small set of service provider interfaces used to adapt or
|
|
extend the Controls runtime for a specific environment. The audience for
|
|
the SPI set is primary system developers who want to integrate the runtime
|
|
into a specific container or application server environment, implement a
|
|
specific type of interceptor or instantiation factory, etc. All of the
|
|
classes in the SPI set live within the org.apache.beehive.controls.spi.*
|
|
package space.
|
|
|
|
./src/runtime:
|
|
|
|
Contains the Control runtime implementation classes. There are several
|
|
base classes used for code-generated ControlBeans as well as supporting
|
|
runtime classes for properties, contextual services, container integration,
|
|
etc. Control authors or clients should never reference any of these
|
|
runtime classes directly. All of the runtime classes live within the
|
|
org.apache.beehive.controls.runtime.* package space.
|
|
|
|
SOURCE DEPENDENCIES:
|
|
|
|
The dependencies across the various types of Control sources are:
|
|
|
|
api -> spi : API public factory classes depend upon some SPI interfaces
|
|
spi -> api : the SPI classes often consume public classes
|
|
runtime -> api, spi : the runtime classes reference both API and SPI types
|
|
|
|
Note: there are *no* dependencies from public interfaces to runtime classes.
|
|
This relationship is enforced by actually having them compile separately
|
|
(api + spi first, then runtime).
|
|
|
|
SOURCE ANT TARGETS
|
|
|
|
This section describes some of the available ant targets from the Controls
|
|
root directory.
|
|
|
|
ant build:
|
|
|
|
Compiles all annotation type, interface, and class files in the API, SPI, and
|
|
runtime directory and creates build/jars/controls.jar to contain them.
|
|
|
|
ant docs:
|
|
|
|
Generates javadoc documention for all API, SPI, and runtime classes and puts
|
|
them in build/docs. After running this target, you can browse to
|
|
file:build/docs/apidocs/classref_controls/index.html to view them.
|
|
|
|
ant clean:
|
|
|
|
Removes all generated output files from any of the build targets in the top
|
|
level or test directories.
|
|
|
|
TEST INFRASTRUCTURE:
|
|
|
|
The Controls runtime test infrastructure lives under the test subdirectory. It
|
|
includes a variety of test for Controls running in different context, from
|
|
vanilla Junit/java tests to running Controls inside of the various containers
|
|
that are part of the Beehive programming model: JWS, JPF, and nesting inside
|
|
of other controls. More details about the Controls runtime test tools
|
|
can be found at http://wiki.apache.org/beehive/Controls/TestingControls.
|
|
|
|
CONTROLS TEST TARGETS:
|
|
|
|
There are two main test targets for running Controls tests. These should be run
|
|
from within the controls/test directory:
|
|
|
|
ant checkin.tests:
|
|
|
|
These are a set of checkin tests that do shallow testing of a broad range of
|
|
functionality. These should be run and pass 100% before a committer submits
|
|
any Controls runtime changes.
|
|
|
|
ant detailed.tests:
|
|
|
|
This runs all control tests. Since some of them are test cases that are the
|
|
basis of open JIRA issues, THESE TESTS ARE NOT EXPECTED TO PASS 100%. Currently,
|
|
there is no good filter for running the detailed tests that are expected to
|
|
pass, but it has been suggested that this would be a good thing (to enable
|
|
deeper testing of larger changes).
|