src
-main
-java core source files
-resources resources
-test
-java test source code
-resources test resources
target
-classes: byte code compiled from src/main/java and resources in /src/main/resources
-test-classes: byte code compiled from src/test/java and resources in src/test/resources
-surefire-reports: reports generated by surefire plugin after tests are executed
-*.jar files: project artifacts
2. Three types of maven repositories:
-local: local repository (usually .m2 directory under ~ of the user)
-remote: remote repository from which maven files can be downloaded
-mirror: repository managers that mirror various repositories such as Nexus
3. A maven lifecycle is a set of phases that happen in sequence and at each phase, one or more maven goals can be executed. (Goals are generally bound to a specific phase except check-style)
-clean lifecycle: clean phase
-site lifecycle: site phase
-default lifecycle: validate, process-resources, compile, test-compile, test, package, integration-test, verify, install, deploy
4. A project/dependency is uniquely identified by (groupId, artifactId, version)
5. ~/.m2/settings.xml contains all user-level maven configurations that override the system-level configuration as defined in MAVEN_HOME/conf/settings.xml. Some maven settings are:
localRepository; offline; mirror;
repositories; repos for maven dependencies
pluginRepositories; repositories for maven plugins
6. Maven offline mode: (-o option) maven will not download updates/dependencies/plugin from the internet.
7. Three types of maven profiles in descending order of precedence:
-global profiles: defined in MAVEN_HOME/conf/settings.xml
-user profiles: defined in ~/.m2/settings.xml
-project profiles: defined in project pom.xml file
Profiles can be activated by doing any of the following things:
- set activateByDefault to true
- by environment variables
- if the profile is added to activeProfiles in the settings.xml file
- by providing an option in command line -P [profile id]
- OS settings
- Present or missing files
8. Types of maven properties: (which can be referenced by ${property name})
-environment variables
-pom variables: properties of the project prefixed with 'project.' e.g. ${project.version}
-setting variables: properties defined in settings.xml
-java properties: (anything available through System.getProperties())
-normal properties as defined in properties in pom.xml
Note: Any missing property that is defined outside of pom.xml but used as part of a plugin configuration, or defined for different build environment, can break the build
9. The clean lifecycle needs to be explicitly called before the default lifecycle if you need to ensure that the working directory is removed.
Dependency Management
Dependency Scope:
-compile: required for compilation, runtime and tests (as well as testing and runtime)
-test: required for tests (not runtime)
-runtime: required only at runtime, not compilation time
-provided: required for compilation and runtime. But will be provided by users and are therefore not packaged for distribution
-system: required for compilation and runtime, but maven will look up for it explicit at a provided path instead of from the repository
Dependency resolution:
1) Two or more dependencies require the same version of another dependency. Maven
includes a dependency only once
2) If two or more dependencies require a different version of another dependency, Maven resolves this by supporting the nearest definition, which means that it will use the version of the dependency closest to your project in the tree of dependencies
SNAPSHOT vs RELEASE version
A SNAPSHOT version is a version of the project/dependency that has not been released, and it is only available in the SNAPSHOT repository.
1) For release version, maven checks if the artifact is available in local repository before attempting to download from the remote release repository.
2) For SNAPSHOT versions, even if the artifact is available locally, it checks the SNAPSHOT version for updates in the remote repository based on the update policy that can beconfigured
Manually install dependencies that are not available in a repository: mvn install:install-file. (Alternative 1, we could run the deploy goal to install the artifact in the remote mirror.
Alternative 2, we could put the artifact file in a directory under the source repository, declare the local directory as a in-project repository and then install the dependency manually from the in-project repository)
mavn clean package -pl –projects [p1,p2,p3] -am: only execute clean package on the specified set of projects
project inheritance: a pom file can have a parent pom file, from which it can inherit a number of elements, such as dependencies and properties. (In practice, dependency management is done at the parent pom file and child pom files can simply refer the dependencies they need without specification of version/scope/. Similarly plugins can also be managed centrally at parent pom file.) Maven has a super pom that the root pom file of your project inherits from.
By default, maven looks for pom file of the parent pom in the parent folder of where the child is located. If it is not found in the parent folder, maven attempts to download the parent from the repository. You can specify relativePath to tell maven where to find the parent if the parent pom is in a directory other than the parent folder.
Project aggregation: a project can have multiple modules. A Maven command run on the parent pom or the pom file of the aggregate project will also apply to all the modules that it contains.
Project inheritance vs Project aggregation:
1) When project inheritance is used, the parent is not aware of the child. In the case of project
aggregation, each module is not aware of the aggregation.
2) project inheritance is used to share dependencies/properties from parent pom file amongst child pom files, whereas project aggregation is used to build multiple modules
3) The parent pom file is assumed to be in the parent folder of the child pom, the child module is assumed to be in the subfolder of the aggregator project.
relativePath : relativePath of the parent element should point to the appropriate location of the parent
module : The module element should contain the appropriate path to thechild project
No comments:
Post a Comment