Developer Guidelines

Egeria provides technology for an open standard that seeks to improve the processing and protection of data across organizations. For its developers, this carries the benefit that their work receives high recognition, but also additional responsibilities to ensure its wide applicability and longevity.

For example, Egeria seeks a broad audience - from developers to adopting vendors to consuming users. Building this audience and allowing the community to scale requires clarity in the way the software is written, documented, packaged and used. Many of the guidelines seek to make it easier for someone new to pick up the software, at the expense of maybe a little more work, or a little less freedom of action for the original developer.

As such, these guidelines exist to remind us of these broader responsibilities.

Java

The minimum level required to build & run Egeria is Java 8. The code is also buildable under Java 11, but is configured for Java 8 language level and bytecode. It is also runnable under Java 11.

Non-LTS releases are not tested.

The Java distributions we are using include:

All automated builds are performed on Linux (Ubuntu) only using the Azul vm provided by Azure pipelines.

Most developers use MacOS, but Windows should work also.

Problems with any of these should be raised as issues.

Build warnings

Build output should be checked for any warnings ie ‘[WARNING]’ and these should be eliminated.

For example the java compiler is set to use ‘-Xlint:all’ and may report warnings about deprecated function, unsafe casts, unchecked conversions etc which should be addressed.

Other tools used in the build may also result in warnings which should also be addressed, whilst testcases should ensure output is captured to avoid such warnings appear in the build logs.

License text in files

All files for Egeria should have a license included. We are using the Apache 2.0 license, which protects our code whilst still allowing commercial exploitation of the code. There is an example of the license text at the top of this file. The following files in the License-Example-Files directory have the correct license information formatted for different file types to make it easy to use.

Notice that the license information is coded using SPDX.

Documentation

Although all code for Egeria should be clear and easy to read, the code itself can only describe what it is doing. It can rarely describe why it is doing it. Also, the Egeria codebase is quite large and hard to digest in one go. Having summaries of its behaviour and philosophy helps people to understand its capability faster.

README markdown files

Each directory (particularly code modules) should have a README.md file that describes the content of the directory. These files are displayed automatically by GitHub when the directory is accessed and this helps someone navigating through the directory structures.

The exception is that directories representing Java packages do not need README files because they are covered by Javadoc.

Javadoc

Javadoc is used to build a code reference for our public site. It is generated as part of the build. There are three places where Javadoc should be provided by the developer of Java code:

Java code files may have additional comments, particularly where the processing is complex. The most useful comments are those that describe the purpose, or intent of the code, rather than a description of what each line of code is doing.

The output from a build should be checked to ensure there are no javadoc warnings - for example about undocumented parameters or exceptions.

Dependent libraries

New dependencies must only be introduced with the agreement of the broader community. These include frameworks, utility classes, annotations and external packages. This may seem annoying but there are good reasons for this:

If a developer wishes to introduce a new dependency to the Egeria project, they should prepare a short guide (in a markdown file) that explains the value of the new library, how it is to be used and links to more information. They should then present their recommendation to the community and and if agreed by the community, store the guide in the developer resources.

Once in place, the dependency should be maintained across the smallest appropriate number of modules, and should be consistent throughout. - particularly when it may impact consuming technologies.

For more on how dependencies are managed in the codebase refer to Dependency Management.

Coding style and layout

There are many coding and layout styles that provide clear and readable code. Developers can choose the layout they prefer but with the following restrictions/suggestions:

Testing

All code submissions should be accompanied by automated tests that validate the essential behaviour of the code. These automated tests should be incorporated in the build so that they run either at the test or verify stages of the build.

Our preferred Java test frameworks are TestNG and Mockito.


License: CC BY 4.0, Copyright Contributors to the ODPi Egeria project.