Reusing this project

Don't forget to fork me or clone me! This is Public Domain software: it is meant to be reused by you however is sensible. If you fork, take care that upstream pulls work; I'd like to hear from you if you have trouble with forking.

Sensible approaches:

Fork this project, and work from there. You are using this project as a starter. Keep an eye on improvements (usually version bumps on tools and dependencies) that may apply to you. Watch the wiki pages that interest you most: the wiki is continually updated.
Clone this project locally if you want to contribute).

If you cloned this project as a starter, keep up-to-date on improvements:

git remote add upstream https://github.com/binkley/modern-java-practices.git
git fetch upstream
git merge master/upstream

Once you are happy with your project, you should think about removing the upstream remote, and reviewing changes in this repository by hand. Your decision might depend on what merge conflicts you encounter.

Tips

Before pulling from upstream do clean up your local build to avoid mixed results from different code versions. CI does not typically face this issue since it should start fresh each build.
Consider Clone git repository without history? to start at the current tip of this project. For example, some images in README.md started overlarge in earlier versions, something you may not want in a clone.
Caution: Not all the images used in README.md may be in the Public Domain (this is challenging to research). Use due diligence before sharing your clone, and other licenses may apply for these images in a global .context

Irrelevant files

This project includes files which are helpful for maintaining itself, but may be irrelevant to you. Some, however, may prove helpful in specific contexts as noted:

build-as-ci-does.sh — Helpful when CI has steps that local developers do not, and you want to reproduce or explore locally a CI problem. The script should match the actions your CI takes on pushes (this project uses GitHub actions).
compare-tooling-versions.sh — If your project supports both Gradle and Maven builds (unlikely), a quick way to look at dependency and plugin versions between the two. Note that the ouput needs human reading: the same tool version may appear as different lines when comparing.
coverage.sh Checks if the local code passes at given levels of code coverage. The script is focused on Maven, but with edits would do the same for Gradle. This supports the "ratchet" pattern.
run-with-gradle.sh — If you are a Gradle project, you will likely rename this to just run or similar.
run-with-maven.sh — If you are a Maven project, you will likely rename this to just run or similar.

See the code repo for working examples.
This work is dedicated/deeded to the public following laws in jurisdictions for such purpose. The principal authors are:

You can always use the "Pages" UI control above this sidebar ☝ to navigate around all pages alphabetically (even pages not in this sidebar), to navigate the outline for each page, or for a search box.

Here is the suggested reading order:

Reusing this project