1. The build enforces our development standards to reduce the code review load.
2. The build must have a simple developer interface – mvn clean install.
3. If the clean install passes – we can move to source Pull Request (PR).
4. PR is important, as when a PR is merged we may automatically deploy to production.
5. Creating a new project or module must not require a lot of configuration (“xml hell”).
6. A module must not depend on another running Lime Mojito module for testing.
7. Any stub resources for testing must be a docker image.
   • Postgres, Localstack, etc
8. Stubs will be managed by the build process for integration test phase.
   • ie if you’re using stubs, you’re building a failsafe maven plugin IT test case.
9. The build will handle style and code metric checks (CheckStyle, Maven Enforcer, etc) so that we do not waste time in PR reviews.
10. For open source, we will post to Maven Central on a Release Build.

Our very “top” level of build standards is open source and available for others to use or be inspired by:

GitHub: https://github.com/LimeMojito/oss-maven-standards

The base POM files are also available on the Maven Central Repository if you want to use our approach in your own builds.

https://repo.maven.apache.org/maven2/com/limemojito/oss/standards/

These profiles add capabilities to our builds or allow "quick checks" as wanted by the developer.

See article here for why we use maven and how our the POM model works.

Our Open Source Standards library supports the following module types (archetypes) out of the box:

• The plugin update requires manual checks as it is a report.
• Version updates automatic and are configured to skip alpha, beta, rc and old date format versions.
• maven-versions-plugin has backup poms disabled as VCS is here.

   mvn versions:display-plugin-updates | more

mvn versions:update-parent
mvn versions:update-properties
mvn versions:use-latest-releases

For just running version updates on git using OSS lime mojito, there is a pre-canned workflow at .github/actions/oss-maven-patch-version.yml that updates and creates a PR. Suggest configuring to run daily on a repository.

See Article: https://limemojito.com/version-dependency-updates-automated-in-maven/

This example will do all the below with only 6 lines of extra XML in your maven pom.xml file:

• enforce your dependencies are a single java version
• resolve dependencies via the Bill of Materials Library
• Enable Lombok for easier java development with less boilerplate
• Configure CheckStyle for code style checking against our standards at http://standards.limemojito.com/oss-checkstyle.xml
• Configure optional support for docker images loading before integration-test phase
• Configure Project Lombok for Java Development with less boilerplate at compile time.
• Configure logging support with SLF4J
• Build a jar with completed MANIFEST.MF information including version numbers.
• Build javadoc and source jars on a release build
• Configure code signing on a release build
• Configure maven repository deployment locations (I suggest overriding these for your own deployments!)

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>my.dns.reversed.project</groupId>
    <artifactId>my-library</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>jar</packaging>
    <parent>
        <groupId>com.limemojito.oss.standards</groupId>
        <artifactId>jar-development</artifactId>
        <version>15.2.0</version>
        <relativePath/>
    </parent>
</project>

When you add dependencies, common ones that are in or resolved via our library pom.xml do not need version numbers as they are managed by our modern Bill of Materials (BOM) style dependency setup.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>my.dns.reversed.project</groupId>
    <artifactId>my-library</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>jar</packaging>
    <parent>
        <groupId>com.limemojito.oss.standards</groupId>
        <artifactId>jar-development</artifactId>
        <version>15.2.0</version>
        <relativePath/>
    </parent>
    <dependencies>
        <dependency>
            <groupId>software.amazon.awssdk</groupId>
            <artifactId>sns</artifactId>
        </dependency>
    </dependencies>
</project>

Supported for testing with test-utilities and JavaSupport.class - see Article.

Using Ant to perform tasks without writing a maven plugin. If statements and simple execs. Article

• Graal, native and why SnapStart
• SnapStart Advanced Optimisation
• SnapStart and SQL

Modern lambda code and tight integrations with AWS lean to unit testing logic on top of DynamoDb. SQS. etc. While Docker is enabled by default for Integration Tests (*IT) by default, you can enable it so that docker can be used as a resource in Unit Tests. Note that unit tests should still fulfill "class and 1st degree of resources" approach so that assertions are specific to the class under test.

For existing test utilities, it is required to set the Spring Profile to "integration-test" so that localstack resources, etc, spin up as expected.

<properties>
  ...
    <docker.unit.test>true</docker.unit.test>
  ...
</properties>