Maven , mvn , Flags, Multi-Module, repositories, distributionManagement, dependencyManagement, dependencies

https://stackoverflow.com/questions/11778276/what-is-the-difference-between-pom-type-dependency-with-scope-import-and-wit/38470559#38470559

https://stackoverflow.com/questions/25277866/maven-command-line-how-to-point-to-a-specific-settings-xml-for-a-single-command/25279325#25279325

https://blog.sonatype.com/2009/10/maven-tips-and-tricks-advanced-reactor-options/

https://stackoverflow.com/questions/4023597/specify-pom-xml-in-mvn-command-and-mix-goals-of-other-project/4023629#4023629

https://maven.apache.org/pom.html#repositories

https://maven.apache.org/pom.html#distribution-management

https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/maven?view=azure-devops

https://www.baeldung.com/spring-maven-bom

https://www.baeldung.com/maven-multi-module

• The dependencyManagement section only declares the dependencies and their details in the current project - the purpose is management of the details and re-use in other projects, either via inheritance (parent) or import (scope). This is like declaring a data type in program and make it available for use.
• The dependency section defines the actual use of the dependencies in the project, optionally inherit the details (i.e., version, etc.) of the dependencies declared under the dependencyManagment. That's why you will have missing dependencies if you only put them in dependencyManagment. This is analogous to instantiating an variable instance of a data type in a program where it is needed.


• mvn --settings YourOwnSettings.xml clean installStarting with the Maven 2.1 release, there are new Maven command line options which allow you to manipulate the way that Maven will build multi-module projects. These new options are:-rf, --resume-from Resume reactor from specified project-pl, --projects Build specified reactor projects instead of all projects-am, --also-make If project list is specified, also build projects required by the list-amd, --also-make-dependents If project list is specified, also build projects that depend on projects on the list

• mvn -f otherPomFile.xml

•  Whenever a project has a dependency upon an artifact, Maven will first attempt to use a local copy of the specified artifact. If that artifact does not exist in the local repository, it will then attempt to download from a remote repository. The repository/repositories elements within a POM specify those alternate repositories to search. - Basically Download of Binaries from URL.

• distributionManagement specifies where (and how) this project will get to a remote repository when it is deployed. The repository elements will be used for snapshot distribution if the snapshotRepository is not defined.Basically Upload of Binary to URL.
• Bill of Materials -Maven - BOM
        BOM stands for Bill Of Materials. A BOM is a special kind of POM that is used to control the versions of a project’s dependencies and provide a central place to define and update those versions.
        BOM provides the flexibility to add a dependency to our module without worrying about the version that we should depend on.

# Maven
# Build, test, and deploy with Apache Maven
- task: Maven@3
  inputs:
    #mavenPomFile: 'pom.xml' 
    #goals: 'package' # Optional
    #options: # Optional
    #publishJUnitResults: true 
    #testResultsFiles: '**/surefire-reports/TEST-*.xml' # Required when publishJUnitResults == True
    #testRunTitle: # Optional
    #codeCoverageToolOption: 'None' # Optional. Options: none, cobertura, jaCoCo. Enabling code coverage inserts the `clean` goal into the Maven goals list when Maven runs.
    #codeCoverageClassFilter: # Optional. Comma-separated list of filters to include or exclude classes from collecting code coverage. For example: +:com.*,+:org.*,-:my.app*.*
    #codeCoverageClassFilesDirectories: # Optional
    #codeCoverageSourceDirectories: # Optional
    #codeCoverageFailIfEmpty: false # Optional
    #javaHomeOption: 'JDKVersion' # Options: jDKVersion, path
    #jdkVersionOption: 'default' # Optional. Options: default, 1.11, 1.10, 1.9, 1.8, 1.7, 1.6
    #jdkDirectory: # Required when javaHomeOption == Path
    #jdkArchitectureOption: 'x64' # Optional. Options: x86, x64
    #mavenVersionOption: 'Default' # Options: default, path
    #mavenDirectory: # Required when mavenVersionOption == Path
    #mavenSetM2Home: false # Required when mavenVersionOption == Path
    #mavenOptions: '-Xmx1024m' # Optional
    #mavenAuthenticateFeed: false 
    #effectivePomSkip: false 
    #sonarQubeRunAnalysis: false 
    #sqMavenPluginVersionChoice: 'latest' # Required when sonarQubeRunAnalysis == True# Options: latest, pom
    #checkStyleRunAnalysis: false # Optional
    #pmdRunAnalysis: false # Optional
    #findBugsRunAnalysis: false # Optional

Dependency Management vs Dependencies POM Maven Difference

What is the difference between dependencyManagement and dependencies?

https://stackoverflow.com/questions/11778276/what-is-the-difference-between-pom-type-dependency-with-scope-import-and-wit/11782691#11782691

Its need to declare dependencies in child project pom's anyway even if they declared in parent project's pom at <dependencyManagement> section

You cannot have a pom type project as a simple dependency in another project. (Well, you can - but it will not do anything useful). There can only be a parent-child relationship. This is essentially managing dependency through inheritance.

import scope for pom type dependency in <dependencyManagement> section allows you to achieve the equivalent of multiple inheritance.

You can only import managed dependencies. This means you can only import other POMs into the dependencyManagement section of your project's POM. i.e.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>other.pom.group.id</groupId>
            <artifactId>other-pom-artifact-id</artifactId>
            <version>SNAPSHOT</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>   
    </dependencies>
</dependencyManagement>

What then happens is that all the dependencies defined in the dependencyManagement section of the other-pom-artifact-id are included in your POM's dependencyManagement section. You can then reference these dependencies in the dependency section of your POM (and all of its child POMs) without having to include a version etc.