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: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Date Mon, 08 May 2017 17:08:00 GMT
Hi Dan,

On 08/05/17 18:48, Dan Tran wrote:
> Hi Karl
>
> I think you already made changes to the the plugin,  but will file ticket
> to make it official

https://github.com/mojohaus/flatten-maven-plugin/issues/41

Already done by your ticket..

Kind regards
Karl Heinz


>
> -D
>
> On Thu, May 4, 2017 at 10:09 PM, Karl Heinz Marbaise <khmarbaise@gmx.de>
> wrote:
>
>> Hi Dan,
>>
>> On 05/05/17 02:30, Dan Tran wrote:
>>
>>> is flatten-maven-plugin threadsafe?   if not, we have a problem with large
>>> project where multhreaded build is a must have
>>>
>>> maven 3.5 displays a warning on flatten-maven-plugin not thread safe
>>>
>>
>> I need to take a look...can you file in a ticket on flatten-maven-plugin..
>>
>> Thanks.
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>>
>>> Thanks
>>>
>>> -D
>>>
>>> On Thu, May 4, 2017 at 2:52 PM, Karl Heinz Marbaise <khmarbaise@gmx.de>
>>> wrote:
>>>
>>> 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.patrick@oracle.com]
>>>>> Sent: Thursday, May 4, 2017 3:18 PM
>>>>> To: Maven Users List <users@maven.apache.org>; info@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:khmarbaise@gmx.de]
>>>>> Sent: Thursday, May 04, 2017 3:16 PM
>>>>> To: Robert Patrick; Maven Users List; info@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=RoP1Y
>>>>>> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr
>>>>>> _pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=by9ucii
>>>>>> pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE&e=
>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
>>>>>> raclecorp.com_artifactory_repo1&d=DwIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGYB
>>>>>> RbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=mQrJO
>>>>>> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=oPO-3-7EEwzSMAr8-re0YxZdReMu1
>>>>>> 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:[unk
>>>>>> nown-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=RoP1YumCXCgaWHvlZYR8
>>>>>> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
>>>>>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=Gpqh8tXn87EJPGvORYVRoH
>>>>>> 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=RoP1YumCXCgaWHvlZYR8
>>>>>> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
>>>>>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=kjqcy_wD0H5qwfISMGTZrq
>>>>>> XoHWM-jV5GAbTtEvug-bc&e=
>>>>>> delException
>>>>>>
>>>>>>
>>>>>> Did I miss something?
>>>>>>
>>>>>> Thanks,
>>>>>> Robert
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Karl Heinz Marbaise [mailto:khmarbaise@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: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_b
>>>>>>> log_&d=DwIFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmb
>>>>>>> ofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&m=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4A
>>>>>>> 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-tIg6oKuGYBRbr
>>>>>>> MXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&
>>>>>>> m=mQrJOCEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=0PY7XDt7qFb0
>>>>>>> WfiWMn1CIgxZ2Q6apBhIlOqIgfU0A3A&e= > 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.
>>>>>>>>>>>

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


Mime
View raw message