Parent POM entires and Effective POM

[patb23]

Hi,
I have defined a Parent POM to use the latest versions of Spring Integration and Spring Data projects

In the Web Module (that inherits from the parent POM), the effective POM shows a different older version. I thought this could be because of Spring Projects and their dependency. Later, when I copied the POM entries from Parent and pasted in the Web Module's POM, I got the right versions. I am using Spring STS with Maven 3.0.3.  
I am relatively new to Maven and am not sure whether I am not following any standards. Would share the POM entries, if required.
Thanks

[Wayne Fay]

> In the Web Module (that inherits from the parent POM), the effective POM
> shows a different older version. I thought this could be because of Spring
> Projects and their dependency. Later, when I copied the POM entries from
> Parent and pasted in the Web Module's POM, I got the right versions. I am
> using Spring STS with Maven 3.0.3.

What is the version number of the parent and child from their pom.xml
files? If the versions are not snapshots, then Maven is most likely
doing things properly and you do not recognize some important aspects
of releases vs snapshots.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[patb23]

The parent has a 1.0 with no RELEASE OR SNAPSHOTs and the child poms do not specify the version explicitly.

These are the projects that I am not getting correctly.

                <spring.batch.admin>1.2.1.RELEASE</spring.batch.admin>
                <spring.data.version>1.1.0.BUILD-SNAPSHOT</spring.data.version>
                <spring.integration.version>2.1.0.RELEASE</spring.integration.version>
                <spring.framework.version>3.1.0.RELEASE</spring.framework.version>
                <spring.batch.version>2.2.0.BUILD-SNAPSHOT</spring.batch.version>
when I specify these properties in the web module's POM, the effective POM reflects the same.
I would read further on the topic outlined by you.

[Ron Wheeler]

Could it perhaps be caused by putting the dependency in the parent as a
dependency rather than a version in the dependency management section?

You might want to reread the Maven documentation or one of the books
about using a parent POM to manage versions.

It works fine if you do it right.

Ron

On 24/04/2012 12:10 PM, Wayne Fay wrote:

>> In the Web Module (that inherits from the parent POM), the effective POM
>> shows a different older version. I thought this could be because of Spring
>> Projects and their dependency. Later, when I copied the POM entries from
>> Parent and pasted in the Web Module's POM, I got the right versions. I am
>> using Spring STS with Maven 3.0.3.
> What is the version number of the parent and child from their pom.xml
> files? If the versions are not snapshots, then Maven is most likely
> doing things properly and you do not recognize some important aspects
> of releases vs snapshots.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[patb23]

Yes. I just saw this note under 'Best Practices'

"Maven uses the depth of a dependency in the tree when resolving conflicts using a nearest-wins approach. Using the dependency grouping technique above pushes those dependencies one level down in the tree. Keep this in mind when choosing between grouping in a pom or using dependencyManagement in a parent POM".
I was grouping the dependencies in the parent. Thanks for the information.

[Wayne Fay]

> 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.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Ron Wheeler]

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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Curtis Rueden]

Hi everyone,

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

[Curtis Rueden]

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 <[hidden email]> wrote:

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

[Wayne Fay]

> 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 never said that I expect the module level POMs to have the version.
They should inherit that from a (top) parent which should have the
version in a dependentManagement section.

I simply do not believe there is much to gain from having this in the
parent (which is what he seems to be doing):
<my.dep.version>1.2.3</my.dep.version>
<depMgmt>...<dep><g/></a><version>${my.dep.version}</version></dep>

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Wayne Fay]

> 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?

This is what you are looking for:
http://maven.apache.org/pom.html#Dependency_Management

And more documentation in the Sonatype book:
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-dependencies.html

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Jörg Schaible]

Wayne Fay wrote:

>> 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 never said that I expect the module level POMs to have the version.
> They should inherit that from a (top) parent which should have the
> version in a dependentManagement section.
>
> I simply do not believe there is much to gain from having this in the
> parent (which is what he seems to be doing):
> <my.dep.version>1.2.3</my.dep.version>
> <depMgmt>...<dep><g/></a><version>${my.dep.version}</version></dep>

http://repo1.maven.org/maven2/com/thoughtworks/xstream/xstream-
parent/1.4.2/xstream-parent-1.4.2.pom

IMHO, it is much easier to get an overviewand it is a lot less error-prone
if some artifacts share the same version (e.g. ejb and ejb-client). And if I
look at our companies master POM with ~500 version entries ... ;-)

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[stephenconnolly]

My only use for versions specified by property is where the suite of
dependencies are all the same version. Properties is the only way right now
to handle that. Pom v5 should have something better when we get to it
shouldn't it, eh!

On Tuesday, 24 April 2012, Wayne Fay wrote:

> > 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?
>
> This is what you are looking for:
> http://maven.apache.org/pom.html#Dependency_Management
>
> And more documentation in the Sonatype book:
>
> http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-project-dependencies.html
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] <javascript:;>
> For additional commands, e-mail: [hidden email]<javascript:;>
>
>