Hi again,

> I have seen people refer to a mystical "depMgmt" element but see no
> mention of it in the Maven POM Reference.


Heh, I should do my research properly. Looks like people are just
abbreviating "dependencyManagement" which does exist in the POM reference:

"dependencyManagement: is used by POMs to help manage dependency
information across all of its children. If the my-parent project uses
dependencyManagement to define a dependency on junit:junit:4.0, then POMs
inheriting from this one can set their dependency giving the groupId=junit
and artifactId=junit only, then Maven will fill in the version set by the
parent."

I'll have to give it a try!

Sorry for the noise,
Curtis


On Tue, Apr 24, 2012 at 1:01 PM, Curtis Rueden <[email protected]> wrote:

> Hi everyone,
>
>
> On Tue, Apr 24, 2012 at 12:51 PM, Ron Wheeler <
> [email protected]> 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 <
> [email protected]> 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<[email protected]>
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: [email protected]
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>

Reply via email to