Workspace profiles help to solve the following problem for Java systems: If a workspace has been set up using for example an Eclipse workspace import, these root directories likely do not exist on the build server but only on a developer's machine. (Integration of Sonargraph-Build on the build server is described in more detail in the user manual of Sonargraph-Build.) In order to run the same checks with Sonargraph on the build server, a workspace profile defines transformation of root directories. Currently this applies only to Java class root directories. The transformation is done using an arbitrary number of profile patterns that consist of regular matchers and replacement expressions. The profile name can then be applied in the Sonargraph-Build configuration.
Each profile pattern consists of three parts:
-
Module name matcher: Regular expression matching module names. Only if this pattern matches, the module's root path will be applicable for transformation by this profile pattern.
-
Root path matcher: Regular expression matching against the identifying path of roots of the matched module.
-
Root path replacement: This pattern defines the new path that will be used to create a new root directory for this module and replace the existing path. Capturing groups that are used in the module name and root path matchers are accessible.
The two matchers are logically combined, so the capturing groups' indices of the root path matchers do not necessarily start at 1, but depend on the number of capturing groups in the module name matcher. Alternatively, named capturing groups can be used, as illustrated in the following example:
Let's assume that every module of the system has the same layout and has a root path with the identifying path "./target/classes", but you need to map that path to "./target/<module_name>-0.0.1-SNAPSHOT.jar". The three parts that make up the profile pattern can be defined as shown in the following screenshot. A detailed explanation is given below the screenshot.
-
Module name matcher: "(.*:)*(?<module>.*)" - This regular expression matches all module names and keeps the module name in a named capturing group "module" that allows re-using the module's name for the JAR file. If the module has been created by a Maven import and the name matches the schema groupId:artifactId, the groupId will be omitted by the first optional capturing group.
-
Root path matcher: "(?<path>.*/target)/.*" - This regular expression matches against the identifying path of roots of the matched module. The part that needs to be re-used is made available via another named capturing group "path".
-
Root path replacement: "${path}/${module}-xxx.jar" - This pattern defines the new root path that replaces the match. The named capturing groups are used to insert the part of the original path that needs to be re-used and also the module name.
The next pattern replaces the "xxx" string with the correct version using a "standard" unnamed capturing group. It is a matter of taste if you want to split the transformation into several profile patterns or do it in one step.
NOTE
All root directories must be mapped! If profile patterns result in the same mapping for different root directories of the same module, only one directory will be created. Otherwise the same rules apply as for the standard software system workspace: It is not possible that the same root directory is used by different modules.
TIP
More info about the regular expression capabilities can be found in the JavaDoc of java.util.regex.Pattern and its section about capturing groups.
Related topics:
