Gradleビルドツールを使用した新しいオープンソースJavaプロジェクトの作成

Most projects today use git hosted on GitHub. Other options exist, but they are beyond the scope of this article.

To create a new repository, take the following actions:

At the very least, provide essential information, in a README , that helps your users understand what the project is about, how it can help them if they can use it, and how they can contribute to it.

And now, let's get to the 'meaty' part.

I created a build.gradle.kts file and defined a group and version .

group = "sh.props"
version = project.version

The version is implicitly loaded from the project and can be specified in a gradle.properties file:

version=0.2.0-SNAPSHOT

or by passing it via the command-line, e.g., gradle -Pversion=0.3.0 ...

IntelliJ can easily create subprojects:

• right-click the project and select New Module
• or press Cmd-N
• select Gradle Java module
• fill in the details and you're good to go!

Alternatively, create a new directory and inside of it:

• create a build.gradle.kts file
• create a Maven-like directory structure: src/main/java , src/main/resources , src/test/java , src/test/resources

Include this subproject in the settings.gradle.kts file:

include("java-props-core")

Edit the subproject's build.gradle.kts file and define the following block to set the Java version to 11.

plugins {
    `java-library`
}

java {
    toolchain {
        languageVersion.set(JavaLanguageVersion.of(JavaVersion.VERSION_11.toString()))
    }
}

// additionally also allow incremental builds, speeding up build speed
tasks.compileJava {
    options.isIncremental = true
}

Since props is a library, I wanted to generate source and documentation (Javadoc) JARs.

Luckily, this is super easy to do in Gradle. Again, edit the build.gradle.kts file:

java {
    withJavadocJar()
    withSourcesJar()
}

tasks.create<Zip>("docZip") {
    archiveFileName.set("doc.zip")
    from("doc")
}

I chose the JUnit 5 (Jupiter) framework, for which we need to set up a few things:

First, define a new task that will run the tests when called

tasks.test {
    // Use JUnit Platform for unit tests.
    useJUnitPlatform()

    // limit heap usage to 1G (can we tweaked later)
    // https://docs.gradle.org/7.2/userguide/java_testing.html#sec:test_execution
    maxHeapSize = "1G"
}

As well as the necessary dependencies:

dependencies {
    testImplementation(libs.junit.jupiter.api)
    testRuntimeOnly(libs.junit.jupiter.engine)
}

The libs.junit.jupiter.api notation represents type-safe project dependencies in Gradle. These are defined in the root project settings; see below.

Version catalogs are an incubating feature and must be explicitly enabled.

Edit the settings.gradle.kts file and add the following section:

// enable the incubating feature
enableFeaturePreview("VERSION_CATALOGS")

dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            // define the version once
            version("junit", "5.7.2")

            // then create aliases to each component, referencing the version above
            alias("junit-jupiter-api").to("org.junit.jupiter", "junit-jupiter-api").versionRef("junit")
            alias("junit-jupiter-engine").to("org.junit.jupiter", "junit-jupiter-engine").versionRef("junit")
        }
    }
}

Once the above is done, any tests deployed in **/src/test/java can be run by executing gradle test .

As a codebase grows, it's essential for the code to 'look' the same, as it helps give developers a consistent experience.

The chosen format (style) is less important than doing this from early on. After all, you can always change the style and reformat the codebase in one go later on!

This is, in my opinion, best done by a tool that indiscriminately auto-formats your code (as you write it)!

Checking that a project's coding standard meets minimal quality criteria results in better code!

For this I use checkstyle , which is also very easy to set up with Gradle:

Add the following to settings.gradle.kts :

dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            // make a global version available
            version("checkstyle", "9.0")
        }
    }
}

Then edit the subproject's build.gradle.kts file:

plugins {
    checkstyle
}

checkstyle {
    // will use the version declared in the catalog
    toolVersion = libs.versions.checkstyle.get()
}

Run the check with gradle checkstyleMain .

Hopefully, this tutorial gave you an idea of the first steps you should take towards starting an open-source Java library on GitHub.

So far, I only spent a few hours learning how to do all of these from scratch and had a lot of fun doing it!

Since I haven't ported over any code from the v1 repo, I have probably yet to smooth out all the rough edges. If you end up using it, ping me and tell me how you got on! ( I'd appreciate it! )