maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Heinz Marbaise <khmarba...@gmx.de>
Subject Re: Continuous Delivery with Maven now possible?
Date Thu, 04 May 2017 20:07:37 GMT
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:eric@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.broyer@gmail.com>
>> wrote:
>>
>>> How about everybody read their mail?
>>> (see below)
>>>
>>> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrueden@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message