[MAGNOLIA-1260] replace hard coded version in pom.xml files for dependencies to ${parent.version} Created: 08/Dec/06  Updated: 17/Mar/09  Resolved: 08/Dec/06

Status: Closed
Project: Magnolia
Component/s: build
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Nicolas Modrzyk Assignee: Philipp Bärfuss
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: 0.5h
Time Spent: Not Specified
Original Estimate: 0.5h

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

this is similar to what is done with the openwfe version in the workflow module ...
can do it easily, just waiting for agreement on this one.

Just noticed it while creating a new build from the trunk



 Comments   
Comment by Magnolia International [ 08/Dec/06 ]

There have been discussions on the list with Fabrizio and Philipp as to why we should not do this with ${pom.version} or ${project.version} , as far as I understood, partly because of bugs in the release plugins, partly because you should not really on runtime properties of the pom. I'm not sure where this stands, but its different from the openwfe.version property, since that one is declared with <property> in that same pom.

Philipp, could you check / comment ?

Comment by Fabrizio Giustina [ 08/Dec/06 ]

you should not use a property for any version number that can be changed during a release or deploy.
Using ${parent.version} in particular makes snapshots unusable since when you deploy a snapshot build each module gets a different timestamp in version, so that ${parent.version} it's different from their real version.
Using a version specified in dependencyManagement, on the other hand, break the release plugin since it will not change it during a release:prepare.
At the moment, the only fully supported solution for maven is to leave the full version for each module, just as now.

Comment by Magnolia International [ 08/Dec/06 ]

thanks again for the clarification, Fabrizio

Comment by Nicolas Modrzyk [ 11/Dec/06 ]

not sure I understand Fabrizio's answer, since we're using Maven release plugin AND the ${parent.version} thingie for 6 months here now, and it works for both use snapshots and release versions ...
am I missing something ?

My build from the trunk was using 3.0.1 version in the war file, while the version was 3.0.2-SNAPSHOT, why is this better again ?

Comment by Fabrizio Giustina [ 11/Dec/06 ]

ok, long answer, there are 3 different issues here:

  • usage of ${parent.version}:
    this break the use of snapshots (but not the release plugin): if you deploy a whole magnolia snapshot build and a user try to link only a few snapshots jars in their build this will not work. Snapshots get a different version number (timestamp) and are not downloaded properly from remote repositories. You will not see any problems if
  • you are not downloading anything (you built the project on your machine)
  • you don't link single snapshots in your pom
  • you don't use snapshots (releases work properly)
  • usage of dependency management
    this simply doesn't work during releases since version numbers are not changed by the release plugin
  • wrong module versions, not updated by the release plugin
    it did happen to me too, and it looks a bug in the release plugin with (some) multiproject builds (I will try to look at it asap).
    There is a workaround for it anyway: after running "mvn release:prepare" wait till poms are locally modified and then stop the build with a CTRL+C. After that run "mvn install" and than restart the release with "mvn release:prepare" again. Pretty annoying, but poms (both released and new snapshots) will be fine.

hope this help

Generated at Mon Feb 12 03:25:12 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.