[
http://jira.codehaus.org/browse/MNG-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=251103#action_251103
]
Chris Price commented on MNG-4297:
----------------------------------
I think there are valid use cases where expressions should be able to be used
as version numbers. At least until mix-ins become available, using expressions
for version numbers allows us to keep our poms DRY in ways that would be
impossible otherwise.
For example, we have the following:
* A super POM that EVERYTHING inherits from
* A "jar" pom that contains settings that we use on our "standard" jars
* A "swc" pom that contains settings we use on swcs.
We have two projects that we release, let's call them "Project A" and "Project
B". Both are multimodule projects and contain both jars and swcs.
Right now, we keep version number constants in the super POM, like:
<properties>
<version.project-a>3.1-SNAPSHOT</version.project-b>
<version.project-b>7.3-SNAPSHOT</version.project-b>
</properties>
Using this pattern, poms from A and B can inherit from the jar/swc parent poms
accordingly, and just specify ${version.project-a} for their version number.
And there is NOTHING that we have to maintain in more than one place.
If we have to have a single "project-a" parent pom that explicitly specifies a
version number, then we are going to have to have the jar/swc parent poms
inherit from that one, and then have the real modules inside of project a
inherit from those. And we'll have to maintain another copy of those jar/swc
poms for project b. With mix-ins we should be able to eliminate that
redundancy, but until then, we are faced with the choice of using expressions
for the version numbers or duplicating all of the content of our jar/swc poms,
and the expressions path seems MUCH more manageable.
> Disallow use of properties in the project coordinates
> -----------------------------------------------------
>
> Key: MNG-4297
> URL: http://jira.codehaus.org/browse/MNG-4297
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
> Reporter: Brian Fox
> Fix For: Issues to be reviewed for 3.x
>
>
> Maven currently allows properties in the groupId, artifactId and version of a
> pom. This causes artifacts to be produced that require full inheritance and
> interpolation before they can be uniquely identified. It also poses potential
> problems if the properties are defined in settings, env or profiles where the
> consumer can't exactly identify the artifact after the fact.
> Allowing properties in the coordinates generally allows bad practices. After
> all, how can you not know what the identify of the project you're working on
> actually is?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
