Thanks,
Eric
On Sun, May 7, 2017 at 9:59 PM, Bernd Eckenfels <e...@zusammenkunft.net>
wrote:
Hello,
Only those specific properties are allowed. If I remember correctly the
reason for it is a mixture between it is not possible to support full
property resolving in this stage of the model builder and the intention
to
harmonize/restrict to familiarly named usecases.
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=
blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/
interpolation/AbstractStringBasedModelInterpolator.java;h=
b47edbe9898b42e25e53afdfb0447ba59183f6a5;hp=cee376f1134db6d78a8bd78ff9f0c7
108d86e448;hb=51cc76c32625be2f807dcf2ffbeb085984729b57;hpb=
181b0215aa1199e152db9d2c08b1a01436547805
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Eric Benzacar <e...@benzacar.ca>
Sent: Monday, May 8, 2017 3:35:46 AM
To: Maven Users List
Cc: i...@soebes.de
Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
I'm confused by something in Karl's blog as well as the instructions for
the flatten-maven-plugin and the actual release notes for Maven 3.5.
In all the above, they talk about the ${revision}, ${sha1}, ${changelist}
parameters. But what is so special about those particular parameters?
Can
I not use any parameter named of my choosing?
Afterall, the ${revision} value is being set by an environment property,
so
can I not just call it ${buildNumber} instead?
Ex:
<groupId>com.soebes.examples.j2ee</groupId> <artifactId>parent</
artifactId>
<version>1.2.1-${buildNumber}</version> <packaging>pom</packaging> ..
<properties> ... <buildNumber>SNAPSHOT</buildNumber> </properties>
Why do I need to use ${revision}?
https://maven.apache.org/maven-ci-friendly.html specifically mentions
the
above parameters. Why?
Thanks,
Eric
On Thu, May 4, 2017 at 9:40 PM, Justin Georgeson <jgeorge...@lgc.com>
wrote:
Yup :)
-----Original Message-----
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 4, 2017 4:52 PM
To: Justin Georgeson <jgeorge...@lgc.com>; Maven Users List <
users@maven.apache.org>; i...@soebes.de
Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now
possible?
External Sender: Use caution with links/attachments.
Hi,
On 04/05/17 22:52, Justin Georgeson wrote:
Also I believe the partial reactor switches don't work for Tycho
builds.
You mean -pl ..option I suppose?
As far as I know Tycho is handling that at the wrong time of the maven
build and furthermore handles in this relationship some other things
wrong
which results in not working things like this..
Kind regards
Karl Heinz Marbaise
-----Original Message-----
From: Robert Patrick [mailto:robert.patr...@oracle.com]
Sent: Thursday, May 4, 2017 3:18 PM
To: Maven Users List <users@maven.apache.org>; i...@soebes.de
Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
External Sender: Use caution with links/attachments.
Hard to train developers to break old habits but thanks... :-)
-----Original Message-----
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; i...@soebes.de
Subject: Re: Continuous Delivery with Maven now possible?
Hi Robert,
Ah now I see the issue.
If you have a multi module build you should use
mvn -pl moduleToBuild clean install
but from root location and don't change into the module directory
cause
this can't work like this.
Kind regards
Karl Heinz Marbaise
On 04/05/17 22:08, Robert Patrick wrote:
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
https://urldefense.proofpoint.com/v2/url?u=http-3A__a&d=DwIDaQ&c=RoP1
Y
umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBG
r
_pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=by9uci
i pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE&e=
https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.
o
raclecorp.com_artifactory_repo1&d=DwIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGY
B
RbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=mQrJ
O
CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=oPO-3-7EEwzSMAr8-re0YxZdReMu
1 5_A4OMXDtdtFyA&e= 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]
https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_
c
onfluence_display_MAVEN_ProjectBuildin&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR
8
PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0
&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=Gpqh8tXn87EJPGvORYVRo
H
s2ncTiyaZSJWc3AEyEsUQ&e=
gException
[ERROR] [Help 2]
https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_
c
onfluence_display_MAVEN_UnresolvableMo&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR
8
PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0
&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=kjqcy_wD0H5qwfISMGTZr
q
XoHWM-jV5GAbTtEvug-bc&e=
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_
b
log_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwm
b
ofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
A YSpzB_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 <https://urldefense
.
proofpoint.com/v2/url?u=http-3A__t.broyer-40gmail.com&d=
DwIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo&r=
dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=
mQrJOCEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=
0PY7XDt7qFb0WfiWMn1CIgxZ2Q6apBhIlOqIgfU0A3A&e= > 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/
----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and
privileged information for the sole use of the intended recipient. Any
review, use, distribution, or disclosure by others is strictly
prohibited.
If you are not the intended recipient (or authorized to receive
information
for the intended recipient), please contact the sender by reply e-mail
and
delete all copies of this message.
