In Hudson, a user can configure a job to require parameters for a build. For example, imagine a test job that takes the bits to be tested as a parameter.
The actual meaning and the purpose of parameters are entirely up to users, so what the concrete parameter implmentation is pluggable. Write subclasses in a plugin and put {@link Extension} on the descriptor to register them.
Three classes are used to model build parameters. First is the {@link ParameterDescriptor}, which tells Hudson what kind of implementations are available. From {@link ParameterDescriptor#newInstance(StaplerRequest,JSONObject)}, Hudson creates {@link ParameterDefinition}s based on the job configuration. For example, if the user defines two string parameters "database-type" and "appserver-type", we'll get two {@link StringParameterDefinition} instanceswith their respective names.
When a job is configured with {@link ParameterDefinition} (or more precisely,{@link ParametersDefinitionProperty}, which in turns retains {@link ParameterDefinition}s), user would have to enter the values for the defined build parameters. The {@link #createValue(StaplerRequest,JSONObject)} method is used to convert thisform submission into {@link ParameterValue} objects, which are then accessibleduring a build.
Instances of {@link ParameterDefinition}s are persisted into job config.xml through XStream.
{@link ParameterDefinition} class uses config.jelly to provide contribute a formfragment in the job configuration screen. Values entered there is fed back to {@link ParameterDescriptor#newInstance(StaplerRequest,JSONObject)} to create {@link ParameterDefinition}s.
After a parameter definition is in the symbol table, it should always be accessed through the read-only IParameterDefinition
interface.
Note that a parameter definition is equal to another parameter definition if they have the same name. Equality is based solely on name, irregardless of any other metadata defined in this object. @author John Mazzitelli
|
|
|
|
|
|