[
https://jira.codehaus.org/browse/MNG-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363737#comment-363737
]
Brandon White commented on MNG-4715:
Prior comments on this bug report from Chris Price, Axel Fontaine, Don Brown,
Nicolas Grobisa, Cameron Rochester, and Esteban Porcelli describe the same
challenges that we experience in our own environment so I won't repeat them
here.
To mitigate the issues we encountered in our own continuous integration-based
development landscape, we implemented a solution that is based on Axel
Fontaine's suggestions from
http://www.axelfontaine.com/2011/01/maven-releases-on-steroids-adios.html.
There are a number of rough edges with our implementation, particularly for
install/deploy, but it has enabled us to centralize our version management in a
small number of POMs instead of replicating the version in every POM. Our
implementation continues to work with maven versions 3.1.1 up to 3.2.5 but we
remain concerned that a subsequent maven release will break some of the
admittedly fragile hacks that we have introduced.
Even if supporting expressions in version fields is the wrong approach
according to the core Maven team, it would be really nice if Maven could
provide some sort of official solution that allows version metadata to be
injected into the POM from outside.
Part of Nicolas Grobisa's comment from 2012 nails this point well:
The essence of the problem comes from Maven wanting to do everything. In some
ways, it is analog to storing the SCM URL inside the POM. For many reasons and
in different scenarios, some of the POM information should be kept outside the
POM, or at least provide the flexibility for users to do it one way or the
other.
version expression constant
---
Key: MNG-4715
URL: https://jira.codehaus.org/browse/MNG-4715
Project: Maven
Issue Type: Improvement
Components: Dependencies, POM
Affects Versions: 3.0-alpha-6, 3.0-alpha-7, 3.0-beta-1
Environment: eclipse linux xp
Reporter: Faruk
Assignee: Jason van Zyl
Priority: Critical
Fix For: 3.2.6
Attachments: untitled.JPG
early versions, we define modules versions with expressions, and set them to
the parent pom,
simply;
{code:xml}
properties
ibb-core-cache.version1.0.1/ibb-core-cache.version
ibb-core-util.version1.0.1/ibb-core-util.version
/properties
{code}
and then, we give this property to modules pom as expression ,
{code:xml}
nameik-plug/name
packagingjar/packaging
version${ibb-core-util.versionn}/version
{code}
but know , it gives an error you know like this,
{noformat}
[WARNING] Some problems were encountered while building the effective model
for ibb-parent:ibb-modules-parent:pom:1.0.0
[WARNING] 'version' contains an expression but should be a constant. @
ibb-parent:ibb-modules-parent:${ibb-core-jars.version},
C:\dev\ibb\workspace\core\ibb-modules-parent\pom.xml
{noformat}
but I think that, this enhancement is causes wrong result,
think that , if we have i project already developing about 3 years, this
project has a lot of modules, and this modules have sub modules , and this
sub modules already bound to some other modules not define in your pom, but
your updates must be affect them, at this situation, developer want to write
the existing version numbers with properties to parent pom, and want to
manage them like this. at the attach file below , the close projects are
belongs to open projects, but they are the different team developing this. I
cant force the other developers to cache their versions, I must use this
versions as initial step
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
