During the development of Signals, our free Alerting solution for Elasticsearch, it became apparent quite soon that we needed to re-think the way our code is structured, and how we ship releases and artifacts. We decided to switch to a multi-module Maven project structure and to release everything on our own Maven server.
Where we started
When we started developing Search Guard, it was clear that we wanted to make our complete code available publicly to our users. We believe that security has to be open by definition.
Mixing ASL2 and proprietory licensed code is a big no-go
At the same time, we wanted to make it very clear what parts of our code are under ASL2 license, and what parts are under a proprietary license. Mixing ASL2 and proprietory licensed code was a big no-go back then, and it still is now.
Skipping version 2 and 5, the repository structure for Search Guard 6 and Search Guard 7 was quite straight-forward:
search-guard: This repository housed the ASL2 licensed Community Edition
search-guard-enterprise-modules: This repository housed the proprietory licensed Enterprise and Compliance Edition code
This structure worked very well for us for a long time. While working on the Signals Alerting project, we decided that it was about time to change how the source code was structured.
Multi-module Maven structure
We decided to switch to a multi-module Maven structure. This helped us a lot to structure the code more clearly and also to manage dependencies between the code parts. In essence, we kept the repository structure regarding ASL2 licensed, and proprietary licensed code but transformed the two repositories into multi-module maven projects. Both repositories have the same structure.
Project structure on Gitlab
All Search Guard code can be found on
https://git.floragunn.com/. To separate the old project structure from the new one, we also gave the repositories new names:
search-guard-suite Contains all modules for the ASL2 licensed Community Edition
This repository has the following modules:
plugin: The descriptors and assembly instructions to build the final plugin
support: Code common to all modules, like helper classes or validation code
scheduler: Quarz-based scheduler which is used for running periodic tasks, like Signals Watches
signals: The Signals Alerting code
security: All Search Guard Security related code
search-guard-suite-enterprise Contains all modules for the proprietory licensed Enterprise and Compliance Edition
This repository has the following modules:
dlic-signals: The Signals Enterprise connectors like JIRA and PagerDuty
dlic-security: The Enterprise and Compliance security features, like field anonymization, DLS, FLS etc.
Search Guard Maven Repository
All artifacts we publish can be found on our
Maven repostory. The Maven repository reflects the git structure closely, so
all modules have their own directory.
The Search Guard plugin, including Security and Alerting, ready to download and install, can be found here:
If you want to use Search Guard to your own Maven project, you need to add the Search Guard Maven repository to your
list of repositories in pom.xml like:
copy<repository>
<id>search-guard</id>
<name>maven.search-guard.com-releases</name>
<url>https://maven.search-guard.com/search-guard-suite-release</url>
</repository>
You then declare dependencies as usual, for example:
Security:
copy<dependency>
<groupId>com.floragunn</groupId>
<artifactId>search-guard-suite-security</artifactId>
<version>7.8.1-43.0.0</version>
</dependency>
Alerting:
copy<dependency>
<groupId>com.floragunn</groupId>
<artifactId>search-guard-suite-signals</artifactId>
<version>7.8.1-43.0.0</version>
</dependency>
Search Guard Kibana plugin
To streamline our naming conventions, we also renamed the repository for the Kibana plugin. We dropped the Kibana major version from the repository names.
Where to go next