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:[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=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-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/


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

Reply via email to