Hi Karl,

If I define the revision property in the top-level POM, I cannot refer to it in 
the module POMs' <parent> elements *and* still retain the ability to build from 
the module directory, right?  I tried this and it failed because it was unable 
to resolve the revision property variable.

C:\rpatrick\work\projects\jcs-las\util>mvn clean install
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-version
]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http://a
rtifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the local reposito
ry, resolution will not be reattempted until the update interval of repo1 has el
apsed or updates are forced and 'parent.relativePath' points at wrong local POM
@ line 7, column 13
 @
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project oracle.jcs.lifecycle:util:[unknown-version] (C:\rpatrick\w
ork\projects\jcs-las\util\pom.xml) has 1 error
[ERROR]     Non-resolvable parent POM for oracle.jcs.lifecycle:util:[unknown-ver
sion]: Failure to find oracle.jcs.lifecycle:app-to-cloud:pom:${revision} in http
://artifactory-slc.oraclecorp.com/artifactory/repo1 was cached in the local repo
sitory, resolution will not be reattempted until the update interval of repo1 ha
s elapsed or updates are forced and 'parent.relativePath' points at wrong local
POM @ line 7, column 13 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please rea
d the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildin
gException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableMo
delException


Did I miss something?

Thanks,
Robert

-----Original Message-----
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] 
Sent: Thursday, May 04, 2017 3:02 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,


On 04/05/17 21:55, Robert Patrick wrote:

> With 3.5, you can now use a variable *but* that variable
 > has to be accessible to the POM prior to finding its  > parent so the only 
 > solution is to move the  >  version number outside the POM hierarchy and 
 > into a -D defined
> variable.

Which is not true. You can define the property inside the pom file if you like 
and can overwrite the version via command line (-Drevision=...).



 > While this works, it seems to have some undesirable
 > aspects to it.  In my opinion, it would be better if
 > Maven could find a way to resolve this issue
 > without resorting to -Ds to specify the
 > value of the variable.
 > I am not sure it is possible but I also worry
 > about moving the version number outside the POM...
>
> Maybe Maven should consider a mechanism by which the project version number 
> can be defined in a separate location that is:
>
> 1.) Well-known so that all resolution can happen directly by interacting with 
> this location directly, without the need to traverse the parent hierarchy
> 2.) It is part of the project structure so that it can be managed in the 
> project's source control system
> 3.) It cannot be overridden at build time with command-line arguments.
> 4.) Has a mechanism by which to reference it from all the necessary locations 
> within the POMs
>
> Maybe something like an optional .mvn/project.version file and a variable 
> that cannot be overridden to refer to it?
>
> -----Original Message-----
> From: Eric Benzacar [mailto:e...@benzacar.ca]
> Sent: Thursday, May 04, 2017 12:53 PM
> To: Maven Users List
> Subject: Re: Continuous Delivery with Maven now possible?
>
> I've read through Karl's blog 
> (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY&s=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk&e=
> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand 
> the approach, there is still one critical issue that bothers me.  I think 
> this actually reopens an old thread that circulated on this list a few months 
> ago, but it related to the Idempotence of a pom file.
>
>>From my perspective/view a pom file should be idempotent.  That is every 
>>single build of a given NON-SNAPSHOT pom file should finish with the same 
>>build.  But by moving a release number or version number outside of the pom, 
>>it eliminates this need.  Furthermore, from a traceability perspective, my 
>>source control can no longer show me precisely version was being 
>>built/developed at any given time.
>
> By leveraging the mvn.config file, I'm a little further down the path, but 
> none the less, the value can be overridden at build time with a completely 
> different value.  Consequently, I can still not be 100% confident that a pom 
> delivered a particular version.
>
> I'm still not 100% sure of the best approach going forward, but I'm thinking 
> that something like the version-plugin being able to manipulate a revision 
> property that can then be committed as part of the pom would be the best of 
> both approaches.  In that way, my developers can fix the version number, but 
> my build system can manipulate the revision property.
>
> Does anyone know if there is a plugin that will allow for that?
>
> Thanks,
>
> Eric
>
>
> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <t.bro...@gmail.com> wrote:
>
>> How about everybody read their mail?
>> (see below)
>>
>> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrue...@wisc.edu> wrote:
>>
>>> Hi Dan, Karl & everyone,
>>>
>>>> See Karl's Blog
>>>
>>> Link, please?
>>>
>> […]
>>
>>>>>> On 03/05/17 20:39, Dan Tran wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I have been experimenting with suggestion from Karl [1] with
>>>>>>> small
>>>> multi
>>>>>>> module maven project.
>>
>> […]
>>
>>>>>>> [1]
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
>>>>>>> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou&d=DwIFaQ&c
>>>>>>> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0i
>>>>>>> ErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
>>>>>>> AYSpzB_W99oBqY&s=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
>>>>>>> e=
>>>>>>> t-a-version-in-it/
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


Mit freundlichem Gruß
Karl-Heinz Marbaise
-- 
SoftwareEntwicklung Beratung Schulung    Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz Marbaise        USt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen                           
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.soebes.de&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=6IAGr4po5BkkfLJYpRCfgqH7OaIePamBF7JGB_W6tbA&s=__Zgpn0s6SLFxUKXhxbaCjPfgjdqUt1eH6CdS582ACI&e=
 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to