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

Thanks

-D

On Thu, May 4, 2017 at 2:52 PM, Karl Heinz Marbaise <khmarba...@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.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=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: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=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 <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
>
>

Reply via email to