maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Rueden <ctrue...@wisc.edu>
Subject Re: Parent POM entires and Effective POM
Date Tue, 24 Apr 2012 18:01:40 GMT
Hi everyone,

On Tue, Apr 24, 2012 at 12:51 PM, Ron Wheeler <
rwheeler@artifact-software.com> wrote:

> If you have the same dependency in many modules and you want to ensure
> that all developers are using the same version
>

This seems like an extremely common, if not ubiquitous, requirement to me.


>  Specifying versions in module level POMs opens the door to a module
> having the wrong version during the build which can show up as a method not
> found if the module was built with a version later than the one provided at
> runtime.
>

I agree. This is the sort of thing the maven-enforcer-plugin is designed to
detect at build time, yes?

http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html

I haven't set it up yet for my team's projects, but am planning to do so
soon. At the moment we are using properties to define version numbers,
which is ugly and does not fully solve the problem anyway, since it does
enforce anyone to use those properties in their submodules.

Alternately (or perhaps in addition), it is not clear to me whether it is
possible to specify dependency versions in a parent POM, which would be
automatically inherited by children, and if so, whether doing things this
way is a good idea. I have seen people refer to a mystical "depMgmt"
element but see no mention of it in the Maven POM Reference. Anybody know
the details?

Regards,
Curtis


On Tue, Apr 24, 2012 at 12:51 PM, Ron Wheeler <
rwheeler@artifact-software.com> wrote:

> On 24/04/2012 1:24 PM, Wayne Fay wrote:
>
>> The parent has a 1.0 with no RELEASE OR SNAPSHOTs and the
>>> child poms do not specify the version explicitly.
>>>
>> Unless you are actively making a release, your version should almost
>> always have the -SNAPSHOT qualifier appended to it. So if you are
>> working on version 1.0, then your pom should show version 1.0-SNAPSHOT
>> until the brief moment in time when you perform the release -- then it
>> will be 1.0 -- and then immediately after it should bump to version
>> 1.1-SNAPSHOT.
>>
>>  <spring.batch.admin>1.2.1.**RELEASE</spring.batch.admin>
>>> <spring.data.version>1.1.0.**BUILD-SNAPSHOT</spring.data.**version>
>>>
>> I can't speak for everyone, but I am definitely not a fan of declaring
>> dependency versions in a tag like this. It just makes things more
>> complicated. When I open a pom, I want to find the version right there
>> along with the GroupId and ArtifactId in<dependency>  or
>> <dependencyManagement>. Managing versions with properties is not a
>> best practice IMO.
>>
> If you have the same dependency in many modules and you want to ensure
> that all developers are using the same version since you likely want it as
> "provided", you will have a lot of maintenance to do.
>
> My "management principle" is that version selection is a project
> management/team function and the developers of individual modules should
> not be concerned about the versions of shared dependencies. If they find a
> problem with the version selected by the team, then this should be raised
> to the team level.
>
> Specifying versions in module level POMs opens the door to a module having
> the wrong version during the build which can show up as a method not found
> if the module was built with a version later than the one provided at
> runtime.
>
> Ron
>
>
>  Wayne
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<users-unsubscribe@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message