From issues-return-100203-apmail-maven-issues-archive=maven.apache.org@maven.apache.org Fri Jan 30 23:34:00 2015 Return-Path: X-Original-To: apmail-maven-issues-archive@minotaur.apache.org Delivered-To: apmail-maven-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C9A1517D07 for ; Fri, 30 Jan 2015 23:34:00 +0000 (UTC) Received: (qmail 78409 invoked by uid 500); 30 Jan 2015 23:34:01 -0000 Delivered-To: apmail-maven-issues-archive@maven.apache.org Received: (qmail 78363 invoked by uid 500); 30 Jan 2015 23:34:01 -0000 Mailing-List: contact issues-help@maven.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@maven.apache.org Delivered-To: mailing list issues@maven.apache.org Received: (qmail 73163 invoked by uid 99); 30 Jan 2015 18:07:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Jan 2015 18:07:21 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [199.193.192.100] (HELO codehaus01.managed.contegix.com) (199.193.192.100) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Jan 2015 18:06:55 +0000 Received: from codehaus01 (localhost.localdomain [127.0.0.1]) by codehaus01.managed.contegix.com (Postfix) with ESMTP id 04745B11AE for ; Fri, 30 Jan 2015 12:06:24 -0600 (CST) Date: Fri, 30 Jan 2015 12:06:24 -0600 (CST) From: "Scott Carey (JIRA)" To: issues@maven.apache.org Message-ID: In-Reply-To: References: Subject: [jira] (MNG-4715) version expression constant MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 22cf62d5d84cf5bea94eb3b65e0ebd09 X-Virus-Checked: Checked by ClamAV on apache.org [ https://jira.codehaus.org/browse/MNG-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=362138#comment-362138 ] Scott Carey edited comment on MNG-4715 at 1/30/15 12:05 PM: ------------------------------------------------------------ child modules can either: use $\{parent.project.version} or $\{project.version} to be DRY, if the references are the same as the parent not list the version at all and have the parent define it in its dependencyManagement. The only thing you can not do is reference a property in the parent/version. All the child modules in your reactor likely have the same version for their parent versions. To manage that, use the versions plugin (NOT release plugin -- that this is a mess, conflated design, and buggy in my experience, use 'mvn versions:set' instead). There is one situation where the message reported here causes me trouble: I have a corporate parent pom, and I want to have its version available via a property to all children. I can create a property 'corporate.root.version' bound to ${project.version}, but that does not work because children re-evaluate it to their own version. Two options seem to work: duplicate the version string in the corporate root -- once for its own version declaration and again for this property, and hope nobody forgets to modify one without the other, OR have the version string in a property, and reference it in the project version, which leads to the warning message here. Is the value TRULY unstable if the property is defined in this pom, as a constant? I don't believe it is. was (Author: scottcarey): child modules can either: use \$\{parent.project.version} or \$\{project.version} to be DRY, if the references are the same as the parent not list the version at all and have the parent define it in its dependencyManagement. The only thing you can not do is reference a property in the parent/version. All the child modules in your reactor likely have the same version for their parent versions. To manage that, use the versions plugin (NOT release plugin -- that this is a mess, conflated design, and buggy in my experience, use 'mvn versions:set' instead). There is one situation where the message reported here causes me trouble: I have a corporate parent pom, and I want to have its version available via a property to all children. I can create a property 'corporate.root.version' bound to ${project.version}, but that does not work because children re-evaluate it to their own version. Two options seem to work: duplicate the version string in the corporate root -- once for its own version declaration and again for this property, and hope nobody forgets to modify one without the other, OR have the version string in a property, and reference it in the project version, which leads to the warning message here. Is the value TRULY unstable if the property is defined in this pom, as a constant? I don't believe it is. > 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} > > 1.0.1 > 1.0.1 > > {code} > and then, we give this property to modules pom as expression , > {code:xml} > ik-plug > jar > ${ibb-core-util.versionn} > {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)