-
Notifications
You must be signed in to change notification settings - Fork 71
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, I take care that upstream pulls work, but I'd like to hear from you if you have trouble. See also: Cleaning up.
Sensible approaches:
- Fork this project, and work from there, pulling down improvements (usually version bumps on tools and dependencies)
- Clone this project to a new repository, and work from there. Manually pull over improvements (there is tooling to help)
- Read through this repository's code and changes, and update your own repository by hand, useful for existing repositories
If you cloned this project as a starter, you may want to stay updated 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.
- 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
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 justrun
or similar. -
run-with-maven.sh
— If you are a Maven project, you will likely rename this to justrun
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: