Plugins
One of the key feature of xooctory is its flexibility. Indeed xooctory Architecture has been designed to provide a solid core for executing jobs over a grid and collecting results on these jobs execution. But the actual implementation of how and when builds should be performed is provided through plugins.Plugin types
Here is the list of what is meant to be pluggable in xooctory.SCM
Source Control Management implementation is easily pluggable by providing a set of classes giving access to the SCM (checkout, changelog) through a SCMURL: an identification of a unique path in a SCM repository.Classes involved:
org.xoocode.xooctory.plugins.scm.SCMPlugin
org.xoocode.xooctory.scm.SCM
org.xoocode.xooctory.scm.SCMURL
org.xoocode.xooctory.scm.SCMRevision
Example of implementation:
org.xoocode.xooctory.plugins.scm.svn.SubversionPlugin
Job Resource
A job resource is the 'what' in a job plan. This is a persistent information which does not provide any behavior. It is used as a source of data for job procedures and job plan controllers.Classes involved:
org.xoocode.xooctory.plugins.resource.JobResourcePlugin
org.xoocode.xooctory.jobplan.model.JobResource
Example of implementation:
org.xoocode.xooctory.plugins.resource.scm.SCMResourcePlugin
Job Procedure
This is the 'how' in a job plan. A job procedure is like the recipe for jobs, it tells exactly how to perform the job (checkout project from SCM, run ant, ...). It usually depends on a particular kind of job resource (checking out a project requires a SCMResource).Classes involved:
org.xoocode.xooctory.plugins.procedure.JobProcedurePlugin
org.xoocode.xooctory.jobplan.JobProcedure
org.xoocode.xooctory.jobplan.model.JobProcedureModel
Example of implementation:
org.xoocode.xooctory.plugins.procedure.ant.AntJobProcedurePlugin
Job Trigger
A job trigger is a part of a job plan controller, which is the 'when' in a job plan. A job plan controller relies on a set of triggers to determine when a job should be triggered. A job trigger is responsible for triggering a job when a particular event or set of events occur.Classes involved:
org.xoocode.xooctory.plugins.trigger.JobTriggerPlugin
org.xoocode.xooctory.jobplan.JobTrigger
org.xoocode.xooctory.jobplan.model.JobTriggerModel
Example of implementation:
org.xoocode.xooctory.plugins.trigger.scm.SCMChangeTriggerPlugin
Result Collector
A job result collector is responsible for collecting results during or at the end of a job execution. The list of job result collectors to use is configured in the procedure of a job plan (the 'how'). Collecting results during the job execution is preferred, so that users can see the collected results when they occur. It also allows to react to results sooner (a failing test, ...).Result collectors rely on the result publishing service offered by xooctory, and can thus concentrate on result collection itself. The result publishing service allow to publish result items in a result group, classified by categories. The categories allow to configure each different kind of result collected by a single collector, by providing a specific TTL (time to life) for each category. A TTL of never can be used to disable collection of one category of result in a result collector.
For instance, the junit result collector simply scan a directory when junit result file are created by the build, then parse these xml files and convert them in result annotations, a particular kind of result item. The results collected are isolated in 6 categories: success, failure, error, properties, sysout and syserr. Thus you can easily disable properties collection, or assign a shorter TTL to success than failures or errors.
Classes involved:
org.xoocode.xooctory.plugins.result.ResultCollectorPlugin
org.xoocode.xooctory.job.service.JobResultService
org.xoocode.xooctory.job.model.ResultGroup
org.xoocode.xooctory.job.model.ResultCategory
org.xoocode.xooctory.job.model.ResultItem
Example of implementation:
org.xoocode.xooctory.plugins.result.junit.JUnitResultCollectorPlugin