Sorry was to fast with the send button...

On 04/05/17 22:01, Karl Heinz Marbaise wrote:
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

Can you explain what exactly you mean by this?

2.) It is part of the project structure so that it can be managed in
the project's source control system

You can simply use the .mvn/maven.config file for it...


3.) It cannot be overridden at build time with command-line arguments.

Which contradicts the whole idea of making it simple to change the version...


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?

What is the advantage of having a complete different file here? The change on the other hand shouldn't be that hard ...


Kind regards
Karl Heinz Marbaise


-----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


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                           http://www.soebes.de

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

Reply via email to