Skip to content

Reusing this project

B. K. Oxley (binkley) edited this page Apr 3, 2024 · 13 revisions
Reuse

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.

Tips

  • 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.
Clone this wiki locally