- All POMs can have a parent POM. They can share a parent. The parent POMs store common settings (e.g. nexus creds, clover license, fixed versions of plugins)
- POMs can have modules (sub-pom’s). These can have dependencies. Maven will determine order dynamically based on dependencies
- A POM can have 1 and only one top-level artifact. By default, this artifact is what is deployed to Nexus/Artifactory
- The top section of a POM (groupid, artifact, packaging) are properties. These define the thing in question and are immutable.
- The plugins are pulled in at build time and define extra functionality. (e.g. maven-release-plugin can modify the versions, assembly-plugin is a handy way to make tgz/zip/jar files). Often static code scanning tools are brought in this way (e.g. Atlassian Clover)
- The build block defines the build steps by target. Similar to make files, targets can be dependent. Targets, however, are tied to phases so there is a level of abstraction
- Environment settings are pretty much the same as properties with the exception that they can be overridden on the command line (e.g. -Dsetting=value -Dothersetting=value)
All artifact stores think about things as either Snapshots or Releases
- All artifact stores think about things as either Snapshots or Releases
- a candidate of a release (e.g. 1.0-SNAPSHOT aspires to be 1.0).
- You can upload many (albeit modern repos will append timestamps)
- Are often scrubbed periodically (e.g. we keep just 2 weeks and/or latest 2 of any snapshot version)
- Should only be depended on in active development
- One and only one per release
- Redeploys are not allowed (and painful if required - have to manually scrub, clean up SHAs - avoid this)
- Are ensured to be stored forever
- Often the credentials to deploy releases are protected and available only in CI system
- a group merges multiple repositories for maven pom consumption.
- Groups by their nature are not writable