intellimeet
0 likes283 views
The document discusses dependency management in Maven projects. It introduces the pom.xml file, which defines dependencies, plugins, and other build settings. It covers key parts of the pom.xml file like coordinates, dependencies, inheritance, and properties. It also demonstrates how to define modules, resources, and plugins in the pom.xml file.
intellimeet
- 2. Dependency Management (By Ankur Chauhan)
- 3. Introduction to pom.xml file Dependency Management in MultiModule Project Dependency Management for Multiple projects Importing Dependencies. System Dependencies. Goals Demo (Dependency Management in MultiModule Project) Demo (Dependencies Analysis in Project) Demo (Dependency Management in MultiModule Project)
- 4. POM stands for "Project Object Model". It is an XML representation of a Maven project held in a file named pom.xml It contains configurations of plugins to be used during the build process. It generally defines "who", "what", and "where", while the build lifecycle defines the "when" and "how". POM Structure <project> modelVersion Basics (PART - I) Build Settings (PART - II) More Project Information (PART - III) Environment Settings (PART - IV) </project>
- 5. POM.XML Basics (PART I) Maven Coordinates Dependencies Inheritance Aggregation (or Multi-Module) Properties Build Settings (PART II) Base Build Elements Project Build Elements Profile Build Elements More Project Information (PART III) License Organization Developers Contributers Environment Settings (PART IV) Prerequisites Repositories
- 6. POM INTRODUCTION PART I The Basics Maven Coordinates Dependencies Inheritance Aggregation (or Multi-Module) Properties
- 7. Maven Co-ordinates groupId + artifactId = Project Address in the world Syntex = groupId:artifactId GroupId Unique for an organization or a project & acts much like the Java packaging structure does in an operating system. Group ID's do not necessarily use the dot notation. ArtifactId The artifactId is generally the name that the project is known by. It, along with the groupId, create a key that separates this project from every other project in the world
- 8. Project Version1.0 Project Version1.1 Project Version1.2 Project Version1.3 GroupId (Required) ArtifactId (Required) + = + Version 1.1 (Required) groudId:artifactId:1.1 New Address = groupId:artifactId:version To be continued... Confused!! Which Project??? I got it... Add one more parameter i.e. version
- 9. New Problem... project could be in any formate i.e. Jar, war, Ear, rar, Project Version1.0(jar) Project Version1.0(rar) Project Version1.0(ear) Project Version1.0(war) GroupId (Required) + ArtifactId (Required) + Version (Required) = + packaging=jar (Optional) New Address = groupId:artifactId:packaging:version To be continued... Again Confused?? Ooops I got it... Add one more parameter i.e. packaging
- 10. New Problem... (Ocassionally) Project Version1.0(jar) For JDK1.4 support Project Version1.0(jar) For JDK1.7 support Project Version1.0(jar) For JDK1.6 support Project Version1.0(jar) For JDK1.5 support GroupId (Required) + ArtifactId (Required) + Version (Required) = + packaging=jar (Optional) Final Address = groupId:artifactId:packaging:classifier:version + Classifier=1.4 (Optional) Again Confused?? Ooops I got it... Add one more parameter i.e. classifier
- 11. POM INTRODUCTION PART I The Basics Maven Coordinates Dependencies Inheritance Aggregation (or Multi-Module) Properties
- 13. Scope Compile This scope indicates that dependency is available in classpath of project. It is default scope. Runtime This scope indicates that dependency is not required for compilation, but is required during execution. Provided This scope indicates that dependency is to be provided by JDK or web-server/ Container at runtime. Test This scope indicates that the dependency is only available for the test compilation and execution phases. System* This scope indicates that you have to provide the system path. Import* This scope is only used when dependency is of type pom. This scopes indicates that the specified POM should be replaced with the dependencies in that POM's <dependencyManagement> section. To be continued...
- 14. System Path Is used only if the the dependency scope is system. Otherwise, the build will fail if this element is set. The path must be absolute ex. ${java.home}/lib Maven will not check the repositories for the project. but instead checks to ensure that the file exists. If not, Maven will fail the build and suggest that you download and install it manually.
- 15. Question? What maven does for dependencies?
- 16. Manage dependency list. Downloads and links the dependencies for you on compilation and other goals that require them. Brings in transitive dependencies, allowing your list to focus solely on the dependencies your project requires.
- 17. Transitive Dependency Pro - A Pro - B Pro - E Pro - D Pro - C Pro- D & E are Transitive Dependencies for Project A Question- How to Deal with these dependencies? To be continued...
- 18. Optional This dependency will not be imported as a Transitive Dependency. <exclusions> ... </exclusions> Exclusions explicitly tell Maven that you don't want to include the specified project that is a dependency of this dependency. ... <dependencies> <dependency> ... <exclusions> <exclusion> <groupId>...</groupId> <artifactId>...</artifactId> </exclusion> </exclusions> </dependency> ... </dependencies> ...
- 19. POM INTRODUCTION PART I The Basics Maven Coordinates Dependencies Inheritance Aggregation (or Multi-Module) Properties
- 20. Inheritance Demo Project pom.xml pom.xml pom.xml pom.xml Jar 1 v-1.0 Jar 2 v-1.0 Jar 1 v-1.1 Jar 2 v-1.1 Jar 1 v-1.2 Jar 2 v-1.2 Jar 1 v-1.3 Jar 2 v-1.3 module - 1 module - 2 module- 3 module- 4 ?
- 21. Demo Project pom.xml Module - 1 pom.xml Module - 1 pom.xml Module - 1 pom.xml Module - 1 pom.xml Jar 1 v-1.0 Jar 2 v-1.0 Jar 1 v-1.1 Jar 2 v-1.1 Jar 1 v-1.2 Jar 2 v-1.2 Jar 1 v-1.3 Jar 2 v-1.3 <parent> <groupId>...</groupId> <artifactId>...</artifactId> <version>...</version> <relativePath>..</relativePath> </parent>
- 22. All modules know, who is our parent... That's fine But parent project doesn't know about all of these refering modules. How will we achieve this?
- 23. POM INTRODUCTION PART I The Basics Maven Coordinates Dependencies Inheritance Aggregation (or Multi-Module) Properties
- 24. Demo Project pom.xml Module - 1 pom.xml Module - 2 pom.xml Module - 3 pom.xml Module - 4 pom.xml Jar 1 v-1.0 Jar 2 v-1.0 Jar 1 v-1.1 Jar 2 v-1.1 Jar 1 v-1.2 Jar 2 v-1.2 Jar 1 v-1.3 Jar 2 v-1.3 <parent> .... </parent> <modules> <module>module -1</module> ... <module>module -4</module> </modules> Aggrigation
- 25. POM INTRODUCTION PART I The Basics Maven Coordinates Dependencies Inheritance Aggregation (or Multi-Module) Properties
- 26. Properties Properties are the last required piece in understanding POM basics. Their values are accessible anywhere within a POM by using the notation ${X}, where X is the property. They come in five different styles: Env - ${env.PATH} Project - ${project.version} Settings - ${settings.offline} Java System Properties - ${java.home} x: Set within a <properties/> element in the POM. The value of <properties> <someVar>value</someVar> </properies> may be used as ${someVar}.
- 27. POM INTRODUCTION PART II Build Settings Base Build Elements Project Build Element Profile Build Element
- 28. The BaseBuild Element Set <build> <directory>${project.basedir}/target</directory> <outputDirectory>${project.build.directory}/classes</outputDirectory> <finalName>${project.artifactId}-${project.version}</finalName> <testOutputDirectory>${project.build.directory}/test-classes</testOutputDirectory> <sourceDirectory>${project.basedir}/src/main/java</sourceDirectory> <scriptSourceDirectory>src/main/scripts</scriptSourceDirectory> <testSourceDirectory>${project.basedir}/src/test/java</testSourceDirectory> <filters>... </filters> ... </build>
- 29. POM INTRODUCTION PART II Build Settings Base Build Elements Project Build Element Profile Build Element
- 30. Project Build Element <build> <baseBuild ElementSet>...</baseBuild ElementSet> <resources> .... </resources> <plugins>...</plugins> <pluginManagement>...</pluginManagement> <reporting>...</reporting> <build>
- 31. Resources Another feature of build elements is specifying where resources exist within your project. Resources are not (usually) code. They are not compiled, but are items meant to be bundled within your project or used for various other reasons, such as code generation. <resources> <resource> <targetPath>META-INF/plexus</targetPath> <filtering>false</filtering> <directory>${basedir}/src/main/plexus</directory> <includes> <include>configuration.xml</include> </includes> <excludes> <exclude>filters/xyz.properties</exclude> </excludes> </resource> </resources> <testResources> ... </testResources>
- 32. targetPath: Specifies the directory structure to place the set of resources from a build. filtering: is true or false, denoting if filtering is to be enabled for this resource. directory: This element's value defines where the resources are to be found. The default directory for a build is ${basedir}/src/main/resources. includes: A set of files patterns which specify the files to include as resources under that specified directory, using * as a wildcard. excludes: The same structure as includes, but specifies which files to ignore. In conflicts between include and exclude, exclude wins. testResources: The testResources element block contains testResource elements. Their definitions are similar to resource elements, but are naturally used during test phases. Test resources are not deployed.
- 33. Project Build Element <build> <baseBuild ElementSet>...</baseBuild ElementSet> <resources> .... </resources> <plugins>...</plugins> <pluginManagement>...</pluginManagement> <reporting>...</reporting> <build>
- 35. extensions: Extensions are a list of artifacts that are to be used in this build. true or false, whether or not to load extensions of this plugin. It is by default false. In short, extensions are artifacts that activated during build. inherited: true or false, whether or not this plugin configuration should apply to POMs which inherit from this one. Default value is true. configuration: This is specific to the individual plugin. In other words: values within a configuration element are never explicitly required by the POM schema, but a plugin goal has every right to require configuration values. dependencies: The major difference in this case is that instead of applying as dependencies of the project, they now apply as dependencies of the plugin that they are under. executions: It is important to keep in mind that a plugin may have multiple goals. Each goal may have a separate configuration, possibly even binding a plugin's goal to a different phase altogether. executions configure the execution of a plugin's goals.
- 36. Project Build Element <build> <baseBuild ElementSet>...</baseBuild ElementSet> <resources> .... </resources> <plugins>...</plugins> <pluginManagement>...</pluginManagement> <reporting>...</reporting> <build>
- 37. Plugin Management Plugin Management contains plugin elements in much the same way, except that rather than configuring plugin information for this particular project build. it is intended to configure project builds that inherit from this one. This only configures plugins that are actually referenced within the plugins element in the children. The children have every right to override pluginManagement definitions.
- 38. Project Build Element <build> <baseBuild ElementSet>...</baseBuild ElementSet> <resources> .... </resources> <plugins>...</plugins> <pluginManagement>...</pluginManagement> <reporting>...</reporting> <build>
- 39. POM INTRODUCTION PART II Build Settings Base Build Elements Project Build Element Profile Build Element
- 40. Profiles Profiles are specified using a subset of the elements available in the POM itself, and are triggered in any of a variety of ways. They modify the POM at build time. Types of Profile Per Project Per User Global How can a profile be triggered? Explicitly Through Maven settings Based on environment variables OS settings Present or missing files
- 42. Activation Activations are the key of a profile. The power of a profile comes from its ability to modify the basic POM only under certain circumstances. Those circumstances are specified via an activation element. The power of a profile comes from its ability to modify the basic POM only under certain circumstances. <activation> <activeByDefault>false</activeByDefault> <jdk>1.5</jdk> <os> <name>Windows XP</name> <family>Windows</family> <arch>x86</arch> <version>5.1.2600</version> </os> <property> <name>sparrow-type</name> <value>African</value> </property> <file> <exists>${basedir}/file2.properties</exists> <missing>${basedir}/file1.properties</missing> </file> </activation>
- 43. Activation occurs when one or more of the specified criteria have been met. When the first positive result is encountered, processing stops and the profile is marked as active. jdk: activation has a built in, Java-centric check in the jdk element. This will activate if the test is run under a jdk version number that matches the prefix given. os: The os element can define some operating system specific properties shown above. property: The profile will activate if Maven detects a property (a value which can be dereferenced within the POM by ${name}) of the corresponding name=value pair. file: Finally, a given filename may activate the profile by the existence of a file, or if it is missing.
- 44. POM INTRODUCTION PART III More Project Info License Organization Developers Contributers
- 45. Licenses Licenses are legal documents defining how and when a project may be used <licenses> <license> <name>Apache License, Version 2.0</name> <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url> <distribution>repo</distribution> <comments>A business-friendly OSS license</comments> </license> </licenses> distribution: This describes how the project may be legally distributed. The two stated methods are repo (they may be downloaded from a Maven repository) or manual (they must be manually installed).
- 46. POM INTRODUCTION PART III More Project Info License Organization Developers Contributers
- 47. Organization Most projects are run by some sort of organization (business, private group, etc.). Here is where the most basic information is set. <organization> <name>Codehaus Mojo</name> <url>http://mojo.codehaus.org</url> </organization>
- 48. POM INTRODUCTION PART III More Project Info License Organization Developers Contributers
- 50. POM INTRODUCTION PART III More Project Info License Organization Developers Contributers
- 52. POM INTRODUCTION PART IV Environment Settings Prerequisites Repositories
- 54. POM INTRODUCTION PART IV Environment Settings Prerequisites Repositories
- 55. Repositories Dependencies Repository Repositories are collections of artifacts which adhere to the Maven repository directory layout. Plugin Repositories Maven plugins are themselves a special type of artifact. Because of this, plugin repositories may be separated from other repositories
- 56. APPROACH FOR MULTI- MODULAR PROJECT
- 57. pom.xml pom.xml pom.xml pom.xml Jar 1 v-1.0 Jar 2 v-1.0 Jar 1 v-1.1 Jar 2 v-1.1 Jar 1 v-1.2 Jar 2 v-1.2 Jar 1 v-1.3 Jar 2 v-1.3 Demo Project module - 1 module - 2 module- 3 module- 4
- 58. pom.xml pom.xml pom.xml pom.xml Jar 1 v-1.0 Jar 2 v-1.0 Jar 1 v-1.0 Jar 2 v-1.0 Jar 1 v-1.0 Jar 2 v-1.0 Jar 1 v-1.0 Jar 2 v-1.0 Demo Project Solution module - 1 module - 2 module- 3 module- 4 Parent (pom.xml)Jar 1 v-1.0 Jar 1 v-1.0 Jar 2 v-1.0
- 59. APPROACH FOR MULTI- PROJECT
- 60. Project - 1 Project - 2 Project- 3 Project- 4 Organization Jar 1 v-1.0 Jar 2 v-1.0 Jar 1 v-1.1 Jar 2 v-1.1 Jar 1 v-1.2 Jar 2 v-1.2 Jar 1 v-1.3 Jar 2 v-1.3 pom.xml pom.xml pom.xml pom.xml ......... ......... ......... .........
- 61. Project - 1 Project - 2 Project- 3 Project- 4 Organization Jar 1 v-1.0 Jar 2 v-1.0 Jar 1 v-1.0 Jar 2 v-1.0 Jar 1 v-1.0 Jar 2 v-1.0 Jar 1 v-1.0 Jar 2 v-1.0 pom.xml pom.xml pom.xml pom.xml ......... ......... ......... ......... Super Project with Common Dependencies Install this project on your local repository Solution
- 62. DEMO
- 63. THANK YOU