Default plugins:

• jacoco-maven-plugin
• maven-compiler-plugin
• maven-dependency-plugin
• maven-enforcer-plugin
• maven-javadoc-plugin
• maven-source-plugin
• maven-surefire-plugin

Children still need to define:

• groupId, artifactId, version, packaging, (name), description
  ‣ name: either just ${project.artifactId} or unset, except when
    targetting Central, then: ${project.groupId}:${project.artifactId}
• url (per https://central.sonatype.org/pages/requirements.html mandatory)
• licenses: at least one <license>: name, url, (comments)
• developers: at least one <developer>: name, email, organization{,Url}, …
• organization (if not tarent): name, url
• (optionally)
  ‣ (inceptionYear)
  ‣ (mailingLists: mailingList: name, …)
  ‣ …
  ‣ properties (e.g. override some defaults)
    – archiver.copyright (Copyright © ${archiver.copyright.firstyear}–${archiver.copyright.lastyear}; Licensor: cf. version_vendor)
    – javadoc.doclint (8/11="all" 17="all,-missing")
    – javaRelease (8 (default), 11 or 17)
    – (possibly) gmavenplus.javaRelease (1.8 (default), 11 or 17)
    – maven.minimum.version (3.2)
    – project.build.outputTimestamp $(date -u +'%Y-%m-%dT%H:%M:%SZ')
      but needs release plugin beta version to update automatically
      so perhaps don’t do it yet unless reproducible builds are mandatory
      (or do it and update the timestamp manually before every build/release)
    – <sonar.sources>src/main</sonar.sources> (not set by default)
    – <sonar.tests>src/test</sonar.tests> (dito)
• scm: connection, developerConnection, url, tag (HEAD)
• distributionManagement: repository(, snapshotRepository): id, (name), url
  only if neither dstrepo-{central,tarent} profile are used
• (optionally)
  ‣ (modules)
  ‣ (profiles)
    ⇒ predefined:
      – dstrepo-central, dstrepo-tarent (for distributionManagement as above)
      – gpg
      – jdk8orolder (auto-activated)
      – jdk9ornewer (auto-activated), adds --release for javac/javadoc(?)
      – jdk12ornewer (auto-activated), javadoc.doclint:=all,-missing
      - jre-not-below-jdk (auto-activated), workaround for Debian bug #893388
      – with-implicit-dependencies (auto-activated), see below
• build: settings/resources, pluginManagement and plugins not listed above
• (dependencyManagement)
• (dependencies)

Your top-level POM may not use <dependencies> if you use the dependency
tooling (ckdep.sh and depsrc.sh) because these scripts need to be able
to use the POM, in some circumstances, as parent POM. They take care of
adjusting the <packaging>, but you’ll have to place dependencies into a
profile (with-implicit-dependencies) so they are not picked up by these
subtasks accidentally. For a simple example (a one-JAR library) see:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=useful-scripts/rfc822.git;a=blob;f=pom.xml;hb=HEAD

Model: https://maven.apache.org/ref/current/maven-model/maven.html
Full POM reference: https://maven.apache.org/pom.html

Warning: resource filtering eats ${foo}, @foo@, plus ⚠ new: \$ and \@
Do diff all resources between their source and filtered form, not just
main/ but test/ as well, after adopting this parent POM! In resources,
filtered or not, symbolic links are followed, not copied. Both main and
test as of mvnparent 2.0 also operate on resources-filtered by default.

Note: maven.antrun.version is only present because this is inherited
from the Super POM and never used and untested; similarily, we do not
use or test maven.site.version which is injected somehow.

Include org.evolvis.tartools.maven-parent:lib for java.util.logging
(jdk14 jul) initialisation using logger.properties from the classpath.
The org.evolvis.tartools:maven-parent:jar:tests file was renamed to
org.evolvis.tartools:maven-parent-bs:jar:tests for the maven-parent
2.0 release, org.evolvis.tartools.maven-parent:bs:jar:tests for 3.0.

You might want “git check-whitespace” and “git check-emptylines” from
http://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/.gitconfig?rev=HEAD;content-type=text%2Fplain
(needs https://github.com/mirabilos/git-find and pcregrep); pipe
files through “cat -s” or “perl -00pe0” to drop double empty lines.

Some description on ancillary tools:
• ckdep.sh determines dependencies and keeps them in ckdep.lst
  (used for manual licence analysis) and ckdep.mvn (used by
  depsrc.sh), based on scoping implication, reading ckdep.ins
  for shaded embedded code copies (such as ASM in byte-buddy,
  lombok, Spring), ckdep.inc for free-format dependencies such
  as JS files; must be manually enabled and maintained
• cksrc.sh is a configuration file for ckdep.sh, depsrc.sh and
  mksrc.sh, needed if any of them is used; well-commented
• depsrc.sh uses ckdep.mvn with depsrc.xml to create a PKZIP
  archive containing the sources (usually source JARs from
  Central, cksrc.sh can override) of dependencies shipped
• mksrc.sh, which also must be manually enabled as the above,
  archives the source code as present in git (and moves the
  result from depsrc.xml maven-assembly-plugin into place)
• mvnrepo.sh lists dependencies and plugins from the POM in the
  current working directory as links to mvnrepository.com for
  manual up-to-dateness checking in a browser
• sortdeps.sh sorts <dependencies> and <exclusions> that are
  piped through it (strip the surrounding tags and pass only
  the individual dependency/exclusion tags); postprocess the
  entire POM afterwards with: xmlstarlet fo -e UTF-8 -t -
• sortplug.sh does the same for <plugins> sorting any listed
  dependencies with the sortdeps script internally

You’ll need reasonably recent versions of coreutils, git, maven,
mksh, pax and xmlstarlet for most tools; although they have only
been tested on Debian, they should be pretty portable to similar
operating systems.

Have a look at lib/run.sh as an example of how to execute a JAR
using the newly-created classpath file (allowing extra files to
be added to the classpath — unlike with -cp — and multiple Main
classes to be used instead of the one in the manifest only) and
adding to LD_LIBRARY_PATH (commented out; e.g. for JNI), linked
into lib/src/main/resources-filtered/ so it can also be used to
run the JAR once installed, using dependencies from a Maven re‐
pository, listing the JAR filename and its runtime dependencies
inside the resource-filtered script. The JAR manifest also con‐
tains the list of dependencies, which the script falls back to.
The mainClass manifest entry thus is no longer necessary.

Fast local rebuilds: add…
# maven fast
alias mvnf='mvn -Dmdep.analyze.skip=true -Dmaven.test.skip=true -Djacoco.skip=true -Dmaven.javadoc.skip=true -Dmaven.source.skip=true'
… to your ~/.mkshrc or similar shell initialisation files, then
“mvnf package” can be used to quickly locally recompile things,
so you can test changes more easily.
