You left out the <dependencyManagement> section which is where
I
think everything should go. When a sub-module declares a dependency
it only needs to specify the groupId and artifactId. It will pick up
the defaults specified in the dependencyManagement section, which
can be overridden on an as-needed basis.
_____
So you would rather see all the dependencies declared in the dependencyManagement section
of the root pom of the project? And then apply the option 2 from below across all the
sub-modules? The only concern that I have with this option is that we will have a huge!!
section for dependency management. Aside from the huge section in the root pom I think it
is a cleaner approach.
Any other thoughts?
Thank you,
Stefan Negrea
----- Original Message -----
From: "John Sanda" <jsanda(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Friday, March 15, 2013 10:51:29 AM
Subject: Re: Dependency Versions - Makeover
On Mar 15, 2013, at 11:44 AM, Stefan Negrea <snegrea(a)redhat.com>
wrote:
> Hello Everybody,
>
> There is very little consistency in RHQ on where maven plugins and
> dependencies versions are located. Today we have every single
> possible variation allowed by maven. With a project of our size
> this is big problem because of possible conflicts between
> dependencies. Having versions all over the place leads to
> duplication and sometimes use of the same dependency but with
> different version in submodules. This is hard to manage to say the
> least...
>
>
> This is how versions are declared/used today:
> 1) Everything in the room pom:
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>properties-maven-plugin</artifactId>
> <version>1.0-alpha-2</version>
> </plugin>
>
> 2) In the root pom but the versions as a property:
> the property:
> <jboss-jmx.version>4.2.3.GA</jboss-jmx.version>
>
> and then the dependency:
> <dependency>
> <groupId>jboss</groupId>
> <artifactId>jboss-jmx</artifactId>
> <version>${jboss-jmx.version}</version>
> </dependency>
>
> 3) In a submodule (eg. modules/enterprise/server/ear) but use the
> property from root pom:
> property in project root pom:
> <quartz.version>1.6.5</quartz.version>
>
> and then sub-module pom:
> <dependency>
> <groupId>org.opensymphony.quartz</groupId>
> <artifactId>quartz</artifactId>
> <version>${quartz.version}</version>
> </dependency>
>
> 4) Everything in a submodule (eg. modules/enterprise/server/ear):
> <dependency>
> <groupId>org.yaml</groupId>
> <artifactId>snakeyaml</artifactId>
> <version>1.8</version>
> <scope>provided</scope>
> </dependency>
>
> 5) No version at all, inherited from parent poms (eg.
> modules/enterprise/server/jar):
> <dependency>
> <groupId>antlr</groupId>
> <artifactId>antlr</artifactId>
> <scope>provided</scope>
> </dependency>
>
>
> For some dependencies/plugins all 5 variations are used at the same
> time!!!
>
>
> My proposal is to use just two patterns for declaring versions
> going forward:
> 1) Property in room pom:
> <quartz.version>1.6.5</quartz.version>
>
> and then use the property everywhere else:
> <dependency>
> <groupId>org.opensymphony.quartz</groupId>
> <artifactId>quartz</artifactId>
> <version>${quartz.version}</version>
> </dependency>
>
> 2) Where applicable, no version at all in submodule pom but inherit
> from parent poms:
> <dependency>
> <groupId>antlr</groupId>
> <artifactId>antlr</artifactId>
> <scope>provided</scope>
> </dependency>
>
>
> I really like option 2 but it might not be applicable everywhere
> since a sub-module might be the only one using/requiring that
> dependency.
>
>
> I would like to updated all the poms before the github migration
> due to the repository split (core, plugins, helpers). It will be
> easier to make the changes now and we will start on github with
> something consistent across all three projects.
>
>
> Any thoughts? Any other ideas on how to solve this?
>
You left out the <dependencyManagement> section which is where I
think everything should go. When a sub-module declares a dependency
it only needs to specify the groupId and artifactId. It will pick up
the defaults specified in the dependencyManagement section, which
can be overridden on an as-needed basis.
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel