Automatic loading

Shared profiles can be accessed in 3 ways.
The most advanced one is the automatic loading which is detailed below.
The 2 others are the direct references (file path or URL) and the dependency references (repository URL).

Requirements

The automatic loading is part of the Jeyzer integration within R&D projects.
In this respect, Maven (or Gradle) projects for any library or framework must have its own Jeyzer shared profile.

Shared profile storage must follow a naming convention. See below.

The Jeyzer Recorder Agent usage is required, which is anyway the recommended one.

How does it work ?

Jeyzer setup phase

• The master profile is configured to allow the automatic loading of shared profiles.

Build phase (Maven example)

• The library/framework Maven project is built
  Jeyzer patterns could be automatically generated : see Jeyzer annotations.
• The Maven jar plugin generates the jar library, adding the Jeyzer-Repository as Manifest attribute.
  Example : Jeyzer-Repository=base
  The built jar library must be named as <artefactId>.<version>.jar which follows the Maven standard naming convention.
  Note that the version is optional.
• The shared profile files (analysis patterns, monitoring rules and stickers) get deployed in the Jeyzer repository (see below).
  The Maven project artefactId must be used as shared profile name for these files. It must reflect the above jar file name.
  Project version can be used for the storage.

Recording phase

• The Jeyzer Recorder Agent collects the JVM loaded jar file information and store it in the JZR recording.

Analysis phase

• The Jeyzer Analyzer or Jeyzer Monitor will resolve and load the shared profile based on the artefactId contained in the JZR recording.
  The Jeyzer-Repository id and project version can be involved in the shared profile resolution.

Java module variant

The automatic loading can also rely on the Java module name and version.
Loading is performed in the Java module declaration order, always last, meaning after the static ones and the above process jar path resolutions.
As Java modules do not carry external information (like a Jeyzer profile repository id), all profile repositories get therefore scanned.
Since Jeyzer 2.2

Example

To see it in practice, check the Jeyzer demo Maven project on github : it depends on the jeyzer-demo-shared project/library which comes with its own shared profile.
The demo master profile never references directly this shared profile.
Instead, it is resolved and loaded automatically at analysis time.
This demo shared profile is itself stored in a dedicated demo shared repository to illustrate the possibility of creating your own repositories of profiles.
In your Jeyzer installation, a local copy of all the demo profiles (master and shared) is available under the profiles/demo directory.
The demo repository is declared within the profiles/shared-repositories directory.

Naming convention

The shared profile storage in a Jeyzer repository must follow this naming structure (in bold) :

<Jeyzer repository>
    shared
       <Maven project artefactId>
           <project artefactId>_patterns.xml
           <project artefactId>_rules.xml
           <project artefactId>_stickers.xml
           <Maven project version>
               <project artefactId>_patterns.xml
               <project artefactId>_rules.xml
               <project artefactId>_stickers.xml

The content directory is up to you. For example :

• Analysis patterns could be version specific assuming the project is using Jeyzer annotations which may change from one build to another.
• Monitoring rules and stickers could be version agnostic.
  Stickers usually permit to cover several versions.
  Monitoring rules are often general or valid over a set of versions, in which case stickers will get assigned to it.

Loading strategy

The shared profile with a version is loaded first.
The agnostic version profile is loaded in second.
Both are optional.

The Jeyzer repository lookup is driven by the master profile at the pattern, rule and sticker level.
Example for the analysis patterns:

<patterns>
  <dynamic_pattern_sets declared_repository_only="true"/>
  ...
</patterns>

Example for the monitoring rules:

<rules>
  <dynamic_rule_sets declared_repository_only="true"/>
  ...
</rules>

Example for the stickers:

<stickers>
  <dynamic_sticker_sets declared_repository_only="true"/>
  ...
</stickers>

The declared_repository_only will instruct the loading to look only for the Jeyzer-Repository specified originally in the project jar file Manifest.
If set to false, the loading will scan all the available Jeyzer repositories (base, external, demo..) as defined in the Jeyzer setup : this introduces a performance hit in the analysis.