Squore analyzes projects (in a broad sense) to provide high level indicators and produce personalised dashboards and tailored action lists for each kind of connected user. The whole process can be automated, and integrated in a continuous integration framework.
Information generated in this fashion can be refreshed with any desired rate, and the results will be available each time the Squore process concludes a new build. However, this scenario is best suited to a daily cycle at most, where all input files are the result of a daily commit, and results are generated along with the nightly build.
The Squore Eclipse Plugin is destined to operate at a faster rate, the objective being to deliver results during the development process, before files are committed and fed to the continuous integration process. Tightening the processing loop has several consequences for the Squore Eclipse Plugin behavior:
It doesn't need to be connected to a central Squore server to rate a project, unless for project activation / licence validation purposes.
By limiting communication with the server to a minimum, we make sure projects can evolve outside the global rating cycle, but still offer the rating service.
Should the server be unreachable, rating service is still available for a whole week, before being deactivated. Once a connection is available again, and the credentials are validated, the rating capabilities are restored.
It must be able to process and rate a project locally
The Squore Eclipse Plugin embeds the Squore rating module, much like Squore CLI.
This allows us to retrieve data from Data Providers, assemble them, and launch the Squore Analysis and Decision Engines.
Since the core module used for these phases are the exact same one used by Squore Server, the results are identical.
It must use a configuration (in terms of Analysis Model and Data Providers) synchronised with the one installed on Squore Server
Since the Squore Eclipse Plugin uses a Squore rating module, it needs a rating environment, which must be synchronised with the server's, to ensure results equivalence.
The Squore Eclipse Plugin will perform such synchronisation during the product activation, which is a feature available in the Squore Eclipse Plugin preferences page.
It must be able to manage projects using other languages than Java (e.g. C, C++, C# Ada)
The Squore Eclipse Plugin benefits from the Squore source code analyzer, which provides support for several languages (see Squore documentation for more details).
Analysis results will be available at folder and file level.
It must be integrated into the Eclipse IDE, taking advantage of its extendability
The Eclipse plugin development framework offers a number of mechanisms to enhance various parts of the IDE.The added features have been designed to be both unobtrusive and informative.
It must enhance a project's available information by displaying ratings, Action Items, Findings for each compatible object
The added information is assigned to each artefact, which means at project, file, module, class and function level. Each of these elements will have a rating, as well as a list of Action Items and Findings, depending on the model. A search view offering project artefacts sorted by rating is also available.
It must be able to manage local versions, which are dissociated from the source code control versioning mechanism
One of the differences between the Squore Eclipse Plugin and Squore is that Squore Server uses a database to store the project builds across multiple versions, whereas the Squore Eclipse Plugin uses a local file storage mechanism, to maintain a local history.
This allows functions such as DELTA_VALUE
or PREVIOUS_VALUE
to work as expected, and produce trend analysis indicators.
The data used to produce that trend are these of the current version, and the last rated version.