Maven - Get non-inheritable pom version. - maven

Assume a parent pom with version 1.0 and a child pom with version 2.0.
Now I define a dependency like this in the parent.
<dependency>
<groupId>somedep</groupId>
<artifactId>somedep</artifactId>
<version>${project.version}</version>
</dependency>
In the parent, the version evaluates to 1.0, but in child it evaluates to 2.0. Is there a way, in which I can make it evaluate to 1.0 in child too (Ofcourse no version harcoding in parent is permitted)?

EDIT:
If we look in http://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Inheritance, we can see that:
One factor to note is that these variables are processed after
inheritance as outlined above. This means that if a parent project
uses a variable, then its definition in the child, not the parent,
will be the one eventually used.
Which means that you can't rely on variables which get dynamically resolved in parent and child and are of the type `${project.version} if your child and parent have different versions, which is generally not what you'd want but very specific to your case. I guess what you are left over with is to hardcode the dependency in the parent using something like depedencyManagement:
Parent:
<project>
<groupId>example</artifactId>
<artifactId>masta</artifactId>
<version>1.0</version>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>someDep</groupId>
<artifactId>someDep</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>someDep</groupId>
<artifactId>someDep</artifactId>
</dependency>
</dependencies>
</project>
And child:
<project>
<parent>
<groupId>example</artifactId>
<artifactId>masta</artifactId>
<version>1.0</version>
</parent>
<groupId>example.masta</artifactId>
<artifactId>child</artifactId>
<version>2.0</version>
<dependencies>
<dependency>
<groupId>someDep</groupId>
<artifactId>someDep</artifactId>
</dependency>
</dependencies>
</project>
or, indeed, use ${parent.version} explicitly in the child. One thing to note is I'd generally not have aggregator projects like parent introduce any dependencies but have only dependencyManagement.
This is the second approach, without dependency management:
Parent:
<project>
<groupId>example</artifactId>
<artifactId>masta</artifactId>
<version>1.0</version>
<dependencies>
<dependency>
<groupId>someDep</groupId>
<artifactId>someDep</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
</project>
And child:
<project>
<parent>
<groupId>example</artifactId>
<artifactId>masta</artifactId>
<version>1.0</version>
</parent>
<groupId>example.masta</artifactId>
<artifactId>child</artifactId>
<version>2.0</version>
<dependencies>
<dependency>
<groupId>someDep</groupId>
<artifactId>someDep</artifactId>
<version>${parent.version}</version>
</dependency>
</dependencies>
</project>
But I guess none of the approaches actually fully satisfies what you want.

Related

Flatten Plugin: Resolve dependencyManagement of bom without inherited

I created an example project for this problem: https://github.com/robeatoz/flatten-resolve-dependency-management-without-inherited
Following project structure is given:
foo-build as the parent for all modules
foo-module-a as child module
foo-module-b as child module
foo-module-c as child module
foo-dependencies as bom
I used the flatten-maven-plugin and the property revision for CI friendly builds in all modules:
<groupId>stack.overflow</groupId>
<artifactId>foo-build</artifactId>
<version>${revision}</version>
<packaging>pom</packaging>
<properties>
<revision>0.1-SNAPSHOT</revision>
</properties>
The parent (foo-build) manages one external dependency:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>external.artifact</groupId>
<artifactId>module-managed-in-parent</artifactId>
<version>1.2.3</version>
</dependency>
</dependencies>
</dependencyManagement>
The bom (foo-dependencies) manages the foo dependencies:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>stack.overflow</groupId>
<artifactId>foo-module-a</artifactId>
<version>${revision}</version>
</dependency>
<dependency>
<groupId>stack.overflow</groupId>
<artifactId>foo-module-b</artifactId>
<version>${revision}</version>
</dependency>
<dependency>
<groupId>stack.overflow</groupId>
<artifactId>foo-module-c</artifactId>
<version>${revision}</version>
</dependency>
</dependencies>
</dependencyManagement>
I want that the flattened pom of the bom contains only the resolved foo dependencies without the dependencies managed by the parent (foo-build) like this:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>stack.overflow</groupId>
<artifactId>foo-module-a</artifactId>
<version>0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>stack.overflow</groupId>
<artifactId>foo-module-b</artifactId>
<version>0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>stack.overflow</groupId>
<artifactId>foo-module-c</artifactId>
<version>0.1-SNAPSHOT</version>
</dependency>
</dependencies>
</dependencyManagement>
How do you have to configure the flatten-maven-plugin to achieve this?
I already tried <flattenMode>bom</flattenMode>, but then the flattened pom does not resolve the versions:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>stack.overflow</groupId>
<artifactId>foo-module-a</artifactId>
<version>${revision}</version>
</dependency>
<dependency>
<groupId>stack.overflow</groupId>
<artifactId>foo-module-b</artifactId>
<version>${revision}</version>
</dependency>
<dependency>
<groupId>stack.overflow</groupId>
<artifactId>foo-module-c</artifactId>
<version>${revision}</version>
</dependency>
</dependencies>
</dependencyManagement>
With the following configuration
<pomElements>
<properties>remove</properties>
<dependencyManagement>resolve</dependencyManagement>
</pomElements>
the flattened pom contains the managed dependency of the parent:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>stack.overflow</groupId>
<artifactId>foo-module-a</artifactId>
<version>0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>stack.overflow</groupId>
<artifactId>foo-module-b</artifactId>
<version>0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>stack.overflow</groupId>
<artifactId>foo-module-c</artifactId>
<version>0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>external.artifact</groupId>
<artifactId>module-managed-in-parent</artifactId>
<version>1.2.3</version>
</dependency>
</dependencies>
</dependencyManagement>
It would be simpler to change your approach to more client-centric:
Make foo-dependencies a root project (./pom.xml).
with only foo-* dependencies in dependency management section
modules list with a single foo-build module (would be truncated by flatten plugin)
generic project properties (would be truncated by flatten plugin)
Make foo-build an intermediate project (./foo-build/pom.xml).
with third-party dependencies in dependency management section
with build-specific properties or profiles, required by your project (if any)
Retain foo-module-* leaf modules with foo-build as a parent
If you insist on plain project structure (./foo-module-*/pom.xml), you can use relativePath to point parent module, e.g.:
<parent>
<groupId>stack.overflow</groupId>
<artifactId>foo-build</artifactId>
<version>${revision}</version>
<relativePath>../foo-build/pom.xml</relativePath>
</parent>
<artifactId>foo-module-a</artifactId>
This way you will receive:
clear foo-dependencies as you wish;
zero copy-paste for foo-* dependencies;
flexibility to build whatever and however you like in foo-build without side-effects on foo-dependencies (neither now nor in the future).
I have like the exact same usecase and I solved it with the following configuration.
You need to apply a very specific configuration to the flatten-plugin within the pom file of the BOM module:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<configuration>
<updatePomFile>true</updatePomFile>
<pomElements>
<dependencyManagement>expand</dependencyManagement>
</pomElements>
</configuration>
</plugin>
expand means that the dependencyManagement block will be replaced with the one from the effective pom where all references are properly resolved. updatePomFile is necessary because otherwise by default, the flattened pom would not be published for poms with <packaging>pom</packaging>
Here are the relevant parts from the flatten-plugin's documentation:
updatePomFile: https://www.mojohaus.org/flatten-maven-plugin/flatten-mojo.html#updatePomFile
Explanation for expand: https://www.mojohaus.org/flatten-maven-plugin/apidocs/org/codehaus/mojo/flatten/ElementHandling.html#expand
You don't need to change the version with ${revision}, use ${project.version}, take a try

Maven dependencyManagement: inherit dependency version from parent

I want my dependency in dependencyManagement block to inherit a version from spring-boot-parent's dependencyManagement block, but add exclusion to it, so that I don't need to specify that exclusion in each of child modules.
My parent pom inherits from spring-boot-parent:
<artifactId>my-parent</artifactId>
<version>1.0.0-SNAPSHOT</version>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.1.RELEASE</version>
<relativePath/>
</parent>
<dependencyManagement>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
<version>???</version>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencyManagement>
child pom inherits my-parent:
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-log4j2</artifactId>
</dependency>
</dependencies>
I tried several approaches:
When I replace ??? with ${parent.version}, in child module this version is resolved to be my-parent's version: 1.0.0-SNAPSHOT, which is incorrect.
When I replace ??? with ${parent.parent.version}, maven breaks, as it doesn't support such properties
I can fix ??? to be 2.0.1.RELEASE and this will work fine, but if I update the version of spring boot, I have to remember to update the version of this dependency also, which is non-intuitive
I cannot extract 2.0.1.RELEASE as a property in my-parent and use that property as parent version, as maven does not support that.
I could've used property with value 2.0.1.RELEASE inherited from spring-boot-parent pom, but there is none such property, as far as I can see.
Is there a nice way to achieve what I want?
See Possible to have the parent version as Property to give to the children? - the version used to declare your parent can't be repurposed in a way that says "make this reference fixed to mean its interpretation at this point in the graph". Strings are strings and placeholders are placeholders; there's no built-in facility to have some kind of in-between thing. If the parent uses a property to define a dependency version you can reference that property; if it uses a fixed string (as in your case) then you'll need to repeat something in order to define an exclusion. As referenced in the linked question, a common way is something like this:
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.1.RELEASE</version>
</parent>
<properties>
<spring.boot.version>2.0.1.RELEASE</spring.boot.version>
</properties>
<dependencyManagement>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
<version>${spring.boot.version}</version>
<exclusions>
...
You still have to repeat the value in two fields -- so you have to make very sure that you always keep those in sync (parent version and property).
However, the increasingly-popular way to manage this is to declare those versions in a BOM (a "bill-of-materials" pom with the specific purpose of keeping a set of components aligned). Then the dependencyManagement stuff can be imported instead of inherited. Spring Boot has been doing this for a while now; in fact the parent in your example doesn't actually declare the dependencies itself, they come from a different artifact. So instead of inheriting from the parent, you could do something like this (I might have the sequence of these backwards -- I can't remember whether first or last wins):
<properties>
<spring.boot.version>2.0.1.RELEASE</spring.boot.version>
</properties>
<dependencyManagement>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring.boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
<version>${spring.boot.version}</version>
<exclusions>
...
... now, if there are other reasons (beyond just dep mgmt) you wanted to inherit from spring-boot-starter-parent then this won't really help your problem; you'll still need to duplicate. But I suspect that as your project matures you'll want to have a parent of your own devising anyway.

Maven: Reuse single version definition when referencing parent pom

I have the following pom definition (bottom).
I have many child poms (50 projects), requiring me to update all the poms on each release, for example, when moving from 1.0 to 1.1.
How can I define the version in a single place, and reuse it in all the poms?
EDIT- Some motivation about the request: I'd like to make as little footprint as possible when switching version. As little files to change. As little commits to push. Etc.
EDIT - Cannot use parent properties before the parent is loaded.
<parent>
<groupId>info.fastpace</groupId>
<artifactId>parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<artifactId>child-1</artifactId>
I can use parent's properties and reference the parent using relative path instead of version. Example:
Parent:
<groupId>info.fastpace</groupId>
<artifactId>parent</artifactId>
<version>${global.version}</version>
<properties>
<!-- Unique entry point for version number management -->
<global.version>1.0-SNAPSHOT</global.version>
</properties>
Child:
<parent>
<groupId>info.fastpace</groupId>
<artifactId>parent</artifactId>
<version>${global.version}</version>
<relativePath>..</relativePath>
</parent>
<artifactId>child-1</artifactId>
Disadvantage: Requires the parent pom to exist in the file system and make all developers use the same relative file structure.
See more info here.
You can use maven properties to build a single version numbering scheme.
Like this:
<properties>
<my.version>1.1.2-SNAPSHOT</my.version>
</properties>
And then reference it like this:
<version>${my.version}</version>
Look here for more information:
Maven version with a property
The use of properties is recommended when you have multiple dependencies of the same release. For example:
<project>
...
<properties>
...
<dep.jooq.version>3.7.3</dep.jooq.version>
...
</properties>
...
<dependencies>
...
<dependency>
<groupId>org.jooq</groupId>
<artifactId>jooq</artifactId>
<version>${dep.jooq.version}</version>
</dependency>
<dependency>
<groupId>org.jooq</groupId>
<artifactId>jooq-meta</artifactId>
<version>${dep.jooq.version}</version>
</dependency>
<dependency>
<groupId>org.jooq</groupId>
<artifactId>jooq-codegen</artifactId>
<version>${dep.jooq.version}</version>
</dependency>
...
</dependencies>
...
</project>
Instead, if you have to use the same dependency in different points in the POM file or if you are in module and you would use the same dependency version of the parent, I suggest to use the following way:
<project>
...
<dependencyManagement>
<dependencies>
...
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
</dependency>
...
<dependencies>
</dependencyManagement>
...
<dependencies>
...
<!-- The following block could be in a module -->
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<!-- It is no more ncessary to use the version -->
</dependency>
...
<dependencies>
...
</project>

Maven modules are trying to use parent dependencies

I have a maven project where the parent module has a lib directory containing various jars that are necessary for compilation, but aren't included in the final product. When I try to get the children modules to build it fails. It says "The following artifacts could not be resolved" then eventually says "Could not find artifact local_dependency at C:\path\to\project\modules\module_name\lib\local_dependency.jar".
The children modules do not depend on the libraries that the parent uses, however it still wants to include them. Is there an option I need to set to prevent this?
Parent Pom snippet:
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<currentVersion>1.0.0</currentVersion>
</properties>
<groupId>com.project</groupId>
<artifactId>project_artifact</artifactId>
<packaging>pom</packaging>
<version>${currentVersion}</version>
<modules>
<module>modules/module_name</module>
</modules>
<dependencies>
<dependency>
<groupId>group.id</groupId>
<artifactId>local_dependency</artifactId>
<version>1.0</version>
<systemPath>${basedir}/lib/local_dependency.jar</systemPath>
<scope>system</scope>
<optional>true</optional>
</dependency>
</dependencies>
Child pom snippet:
<parent>
<groupId>com.project</groupId>
<artifactId>project_artifact</artifactId>
<version>${currentVersion}</version>
<relativePath>../../</relativePath>
</parent>
<dependencies>
<dependency>
<groupId>net.some.dependency</groupId>
<artifactId>artifact_name</artifactId>
<version>1.0.0</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>com.project</groupId> <!-- The child depends on the parent for the parent's API-->
<artifactId>project_artifact</artifactId>
<version>${currentVersion}</version>
<type>jar</type>
</depdencency>
</dependencies>
So from this, the child pom will attempt to include group.id:local_dependency from project_base/modules/module_name/lib/local_dependency.jar but it doesn't exist and doesn't need to exist.
You can exclude specific transitive dependencies in the dependency declaration. In your case, the following change in the child pom's dependency on the parent should get the build working:
<dependency>
<groupId>com.project</groupId> <!-- The child depends on the parent for the parent's API-->
<artifactId>project_artifact</artifactId>
<version>${currentVersion}</version>
<type>jar</type>
<exclusions>
<exclusion>
<groupId>group.id</groupId>
<artifactId>local_dependency</artifactId>
</exclusion>
</exclusions>
</dependency>
The child inherits the parent's dependencies, whether or not you include the dependency explicitly. Two possible ways to resolve the issue are:
Don't build any jar artifact in the parent - create a sub-module for this and use the sub-module as a dependency in its siblings.
Use a fixed path (not relative to ${basedir}, since this changes in each module build, which tries to resolve the location anew). If you always build from the parent's directory, you could use ${user.dir}.

Estructuration of multi module project. how to packaging modules?

i'm creating the estructure of a multi modul project with maven.
The parent's pom:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven- 4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>cat.base.gpt</groupId>
<artifactId>gpt</artifactId>
<version>0.0.1</version> <!-- application version -->
<packaging>pom</packaging>
<name>gpt</name>
<parent>
<groupId>cat.base.baseframe</groupId>
<artifactId>projecte-pare-baseframe</artifactId>
<version>0.0.11.a</version>
</parent>
<modules>
<module>gpt.domini</module>
<module>gpt.ui</module>
<module>gpt.logica</module>
<module>gpt.ejb</module>
<module>gpt.ear</module>
</modules>
<dependencies>
<!-- dependencies pel testeig TDD -->
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>6.7</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.4</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>1.9.5-rc1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.kubek2k</groupId>
<artifactId>springockito</artifactId>
<version>1.0.4</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.4</version>
<scope>provided</scope>
</dependency>
<!-- A més, en el cas de provatures UI, s'ha d'afegir la següent dependència:-->
<dependency>
<groupId>cat.base.baseframe</groupId>
<artifactId>baseframe-test-swf</artifactId>
<version>1.0.0-SNAPSHOT</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
Ok, first question, i put all the dependencies at paren's pom is this really correct?
and the most interesting part, i don't know hos to compile the grafic interfade project,(i call ui), it's better create a war or create and ear with all the necessary (ui+logica+domini+ejb) i 'm a litlle bit confused about that, i uset o work with projects already estructure created. I hope you to unsderstand my question, i put the rest of pom to keep an eye. ty.
pom's gpt.domini.
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>gpt</artifactId>
<groupId>cat.base.gpt</groupId>
<version>0.0.1</version>
</parent>
<groupId>cat.base.gpt.domini</groupId>
<artifactId>gpt.domini</artifactId>
<packaging>jar</packaging>
<name>gpt.domini</name>
<description>Definició del model de dades i de la façana del servei</description>
</project>
pom's gpt.ear
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>gpt</artifactId>
<groupId>cat.base.gpt</groupId>
<version>0.0.1</version>
</parent>
<groupId>cat.base.gtp.ear</groupId>
<artifactId>gpt.ear</artifactId>
<name>gpt.ear</name>
<packaging>ear</packaging>
<description>Paquet de l'aplicació J2EE</description>
<dependencies>
<dependency>
<groupId>${project.parent.groupId}</groupId>
<artifactId>${project.parent.artifactId}.domini</artifactId>
<version>${project.parent.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>${project.parent.groupId}</groupId>
<artifactId>${project.parent.artifactId}.ejb</artifactId>
<version>${project.parent.version}</version>
<type>ejb</type>
</dependency>
<dependency>
<groupId>${project.parent.groupId}</groupId>
<artifactId>${project.parent.artifactId}.logica</artifactId>
<version>${project.parent.version}</version>
<type>jar</type>
</dependency>
</dependencies>
</project>
pom's gpt.logica
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>gpt</artifactId>
<groupId>cat.base.gpt</groupId>
<version>0.0.1</version>
</parent>
<groupId>cat.base.gtp.logica</groupId>
<artifactId>gpt.logica</artifactId>
<name>climbing.logica</name>
<packaging>jar</packaging>
<description>Implementació del servei</description>
<dependencies>
<!-- de moment nomes el domini -->
<dependency>
<groupId>${project.parent.groupId}</groupId>
<artifactId>${project.parent.artifactId}.domini</artifactId>
<version>${project.parent.version}</version>
<scope>provided</scope>
</dependency>
</dependencies>
</project>
pom's gpt.ejb
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>gpt</artifactId>
<groupId>cat.base.gpt</groupId>
<version>0.0.1</version>
</parent>
<groupId>cat.base.gtp.ejb</groupId>
<artifactId>gpt.ejb</artifactId>
<name>gpt.ejb</name>
<packaging>ejb</packaging>
<description>Publicació d'un servei en forma EJB</description>
<dependencies>
<dependency>
<groupId>${project.parent.groupId}</groupId>
<artifactId>${project.parent.artifactId}.domini</artifactId>
<version>${project.parent.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>${project.parent.groupId}</groupId>
<artifactId>${project.parent.artifactId}.logica</artifactId>
<version>${project.parent.version}</version>
</dependency>
<dependency>
<groupId>${project.parent.groupId}</groupId>
<artifactId>${project.parent.artifactId}.logica</artifactId>
<version>${project.parent.version}</version>
<classifier>tests</classifier>
<scope>test</scope>
</dependency>
<dependency>
<groupId>javax.ejb</groupId>
<artifactId>ejb-api</artifactId>
<version>3.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>jboss</groupId>
<artifactId>jboss-annotations-ejb3</artifactId>
<version>4.2.2.GA</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>2.5.6</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.jboss.client</groupId>
<artifactId>jbossall-client</artifactId>
<version>4.2.3.GA</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
pom's gpt.logica
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>gpt</artifactId>
<groupId>cat.base.gpt</groupId>
<version>0.0.1</version>
</parent>
<groupId>cat.base.gtp.logica</groupId>
<artifactId>gpt.logica</artifactId>
<name>climbing.logica</name>
<packaging>jar</packaging>
<description>Implementació del servei</description>
<dependencies>
<!-- de moment nomes el domini -->
<dependency>
<groupId>${project.parent.groupId}</groupId>
<artifactId>${project.parent.artifactId}.domini</artifactId>
<version>${project.parent.version}</version>
<scope>provided</scope>
</dependency>
</dependencies>
</project>
pom's gpt.ui
here all the dependencies of spring-rich.faces..or better at parent's pom?
packaging like a war?? or inside de module ear?? ty.
Although there is already an accepted answer, I believe it worth to give more information to you as it seems to me that, both the questioner and the accepted answer got messed up with different concepts in Maven.
1) Aggregation vs Parent POM
There are two concepts in Maven often got mixed up. Aggregation (aka Multi-module) POM and Parent POM are something irrelevant, although it is fine to use one POM to serve for both purpose.
Multi-module project aims to describe the aggregation relationship between projects, so that we can build multiple related project as a whole, and all sub-projects are built in the same reactor. Parent project aims to provide shared project settings. It can even exists out of the project structure (e.g. I may have a company-wise parent POM)
Personally I recommend to have a multi-module POM only to declare the aggregation (hierarchy) of projects, and having a separate parent POM to be used to declare shared settings.
i.e.
my-proj // aggregation only
+ my-proj-parent // parent POM
+ my-proj-main
+ my-proj-web
+ my-proj-ear
2) Shared Dependency for POM vs in EAR
Again, these are two separate concepts.
It is fine to put dependencies in parent POM. When you put it there, it means the inherited project is going to have such dependency. There is no right or wrong on this, as long as you know what you are doing (personally I am using different way, will be described later).
However, whether to put shared JARs in EAR and keep skinny WAR, or have a plain EAR with a "full" WAR has nothing to do with your dependency. It is more about the packaging strategy of EAR. Therefore, changing scope of Maven dependency just because you are going to package the project as skinny war, such approach is simply messing up the whole concept of maven dependency. Even more horrible is, when creating your EAR, you need to find out all the dependencies of its included WARs and add it one by one to the EAR POM, that's doubtless not an optimal solution
A pity that current Maven EAR plugin still has no way to declare a skinny war packaging strategy. However there are some workarounds which allow you to do so, without messing around the Maven dependency scope. http://maven.apache.org/plugins/maven-ear-plugin/examples/skinny-wars.html http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html
(Update: The skinny war receipe seems updated and one of the workaround seems gone. http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+problem?focusedCommentId=212631587#comment-212631587 This is to include WAR type POM as POM type, so that we do no need to declare the dependencies again in EAR)
3) Use of shared dependencies in parent POM
As I mentioned before, there is no right or wrong to put dependencies in parent. However you should know that, such way actually means all inherited project is going to have such dependency, which is mostly incorrect.
for example, I have a foo-a and foo-b projects under foo, which both inherits foo-parent. Assume foo-a is using spring-core while whole logic of foo-b has nothing to do with it, if you put spring-core as dependency in foo-parent, when you look at foo-b, it is unncessarily having unrelated dependencies spring-core.
The proper way to do is only include dependencies (and other settings) in parent POM that should be shared across all inherited projects. For example, unit testing related dependencies may be a good choice. Dependencies for integration testing may be another example.
However, it doesn't mean we should declare dependencies in each project individually. One of the biggest problem is such approach is going to be hard to maintain same version of dependencies across the whole project.
In order to solve such issue, my recommendation is to make use of dependencyManagement in parent POM, which declares the version (and maybe other settings like scope, excludes). Declaring dependencyManagement is not introducing actual dependencies in inherited POM. It simply declare: "If you declare such dependency, this will be the settings to use". In each inherited POM, simply declare the dependencies' group and artifact (and maybe some project specific settings), so that you can follow the version declared in parent POM.
Maybe a bit hard to understand, here is an example:
foo-parent
<project>
<dependencyManagement> // dependency management doesn't bring actual dependency
<dependencies>
<dependency>
<groupId>org.springframework<groupId>
<artifactId>spring-core<artifactId>
<version>3.1.0.RELEASE</version>
</dependency>
<dependency>
<groupId>org.hibernate<groupId>
<artifactId>hibernate-core<artifactId>
<version>3.6</version>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies> // actual shared dependency
<dependency>
<groupId>junit<groupId>
<artifactId>junit<artifactId>
<version>4.11</version>
<scope>test</scope>
</dependency>
</dependencies>
.....
<project>
foo-a
<project>
<dependencies>
<dependency> // note: no version declared
<groupId>org.springframework<groupId>
<artifactId>spring-core<artifactId>
</dependency>
// junit dependency is inherited
<dependencies>
<project>
Ok, first question, i put all the dependencies at paren's pom is this
really correct?
No, your shared dependencies should be put in the ear pom. In the other poms you have to reference the shared dependencies using <scope>provided</scope>.
For example in your ear pom add a dipendency:
<dependency>
<groupId>somegroup</groupId>
<artifactId>someartifact</artifactId>
<version>1.0</version>
</dependency>
In the logica and ui module pom, for example, add these lines:
<dependency>
<groupId>somegroup</groupId>
<artifactId>someartifact</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
In this way the dependency artifact is added only once in the ear package.
and the most interesting part, i don't know hos to compile the grafic
interfade project,(i call ui), it's better create a war or create and
ear with all the necessary (ui+logica+domini+ejb) i 'm a litlle bit
confused about that, i uset o work with projects already estructure
created. I hoper unsderstand my question, i put the rest of pom to
keep an eye. ty.
I don't know if I understand it right. EAR is better suited for project that can have multiple war and/or ejb modules. In your case you can get rid of modularization at all and use a single war package.
finally this is my ear's pom.
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>gpt</artifactId>
<groupId>cat.base.gpt</groupId>
<version>0.0.1</version>
</parent>
<groupId>cat.base.gpt.ear</groupId>
<artifactId>gpt.ear</artifactId>
<name>gpt.ear</name>
<packaging>ear</packaging>
<description>Paquet de l'aplicació J2EE</description>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>gpt.domini</artifactId>
<version>${project.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>gpt.ejb</artifactId>
<version>${project.version}</version>
<type>ejb</type>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>gpt.logica</artifactId>
<version>${project.version}</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>gpt.ui</artifactId>
<version>${project.version}</version>
<type>war</type>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<configuration>
<description>GPT</description>
<displayName>Gestió posicions tributarias</displayName>
<encoding>${project.build.sourceEncoding}</encoding>
<version>1.4</version>
<generateApplicationXml>true</generateApplicationXml>
<modules>
<ejbModule>
<groupId>${project.groupId}</groupId>
<artifactId>${project.parent.artifactId}.ejb</artifactId>
<bundleFileName>${project.parent.artifactId}-ejb.jar</bundleFileName>
</ejbModule>
<jarModule>
<groupId>${project.groupId}</groupId>
<artifactId>gpt.logica</artifactId>
<includeInApplicationXml>true</includeInApplicationXml>
</jarModule>
<webModule>
<groupId>${project.groupId}</groupId>
<artifactId>gpt.ui</artifactId>
<contextRoot>/gpt</contextRoot>
</webModule>
</modules>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<configuration>
<excludeScope>runtime</excludeScope>
</configuration>
</plugin>
</plugins>
</build>
</project>

Resources