Issue 33 Design Discussion

This is a design discussion for issue #33. Please read that ticket first for background, context, etc.

The proposed design involves a vanilla, no-dependency Java interface similar to the following:

public interface AlfrescoTechnicalValidation
{
    public List<Map<String,Object>> validate(String sourceLocation, String binaryLocation, String neo4jUrl);
}

Where:

• sourceLocation is the root directory where source code for the extension is located
• binaryLocation is the root directory or ZIP file containing the binaries (AMPs)
• neo4jUrl is the location of a running Neo4J server that the tool can use for its intermediate data

The returned data structure is a list of maps, with each entry in the list representing the result of a single validation criteria. Note that not all validation criteria are checked by the tool yet, and those that aren't are not included in the result list (note: this may change in a future version).

Each map will have keys as follows:

• "criteriaId" - a String identifying the criteria e.g. "API01" (always present in the map)
• "checked" - a Boolean identifying whether this criterion is checked or not (always present in the map)
• "passes" - a Boolean identifying whether the extension passes the criteria or not (optional - omission means the criteria can't be automatically checked)
• "message" - a String describing any supporting information for the given criteria (e.g. evidence) - note that this value can be both multi-line and voluminous (optional)

It's important to note that calling code will need to handle the case where these keys are not present - the tool does not necessarily populate all keys in all cases.

Client code (e.g. a Maven plugin) would refer to this interface in its own code, and there will be a concrete implementation that can be dependency injected at runtime (e.g. via Spring, though it will not be dependent on Spring).