RE: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Also I believe the partial reactor switches don't work for Tycho builds. -Original Message- From: Robert Patrick [mailto:robert.patr...@oracle.com] Sent: Thursday, May 4, 2017 3:18 PM To: Maven Users List ; 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' 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 >
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
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 ; 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' 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
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
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 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 ; 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' 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
RE: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Yup :) -Original Message- From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] Sent: Thursday, May 4, 2017 4:52 PM To: Justin Georgeson ; Maven Users List ; i...@soebes.de Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? External Sender: Use caution with links/attachments. 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 ; 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' 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=RoP1 >> Y >> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBG >> r >> _pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=by9uci >> i pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE&e= >> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc. >> o >> raclecorp.com_artifactory_repo1&d=DwIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGY >> B >> RbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=mQrJ >> O >> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=oPO-3-7EEwzSMAr8-re0YxZdReMu >> 1 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=RoP1YumCXCgaWHvlZYR >> 8 >> PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0 >> & >> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=Gpqh8tXn87EJPGvORYV
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
I'm confused by something in Karl's blog as well as the instructions for the flatten-maven-plugin and the actual release notes for Maven 3.5. In all the above, they talk about the ${revision}, ${sha1}, ${changelist} parameters. But what is so special about those particular parameters? Can I not use any parameter named of my choosing? Afterall, the ${revision} value is being set by an environment property, so can I not just call it ${buildNumber} instead? Ex: com.soebes.examples.j2ee parent 1.2.1-${buildNumber} pom .. ... SNAPSHOT Why do I need to use ${revision}? https://maven.apache.org/maven-ci-friendly.html specifically mentions the above parameters. Why? Thanks, Eric On Thu, May 4, 2017 at 9:40 PM, Justin Georgeson wrote: > Yup :) > > -Original Message- > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] > Sent: Thursday, May 4, 2017 4:52 PM > To: Justin Georgeson ; Maven Users List < > users@maven.apache.org>; i...@soebes.de > Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? > > External Sender: Use caution with links/attachments. > > > > 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 ; 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' 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=RoP1 > >> Y > >> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBG > >> r > >> _pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=by9uci > >> i pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE&e= > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc. > >> o > >> raclecorp.com_artifactory_repo1&d=DwIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGY > >> B > >> RbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=mQrJ > >> O > >> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=oPO-3-7EEwzSMAr8-re0YxZdReMu > >> 1 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.lif
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Hello, Only those specific properties are allowed. If I remember correctly the reason for it is a mixture between it is not possible to support full property resolving in this stage of the model builder and the intention to harmonize/restrict to familiarly named usecases. https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/interpolation/AbstractStringBasedModelInterpolator.java;h=b47edbe9898b42e25e53afdfb0447ba59183f6a5;hp=cee376f1134db6d78a8bd78ff9f0c7108d86e448;hb=51cc76c32625be2f807dcf2ffbeb085984729b57;hpb=181b0215aa1199e152db9d2c08b1a01436547805 Gruss Bernd -- http://bernd.eckenfels.net From: Eric Benzacar Sent: Monday, May 8, 2017 3:35:46 AM To: Maven Users List Cc: i...@soebes.de Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? I'm confused by something in Karl's blog as well as the instructions for the flatten-maven-plugin and the actual release notes for Maven 3.5. In all the above, they talk about the ${revision}, ${sha1}, ${changelist} parameters. But what is so special about those particular parameters? Can I not use any parameter named of my choosing? Afterall, the ${revision} value is being set by an environment property, so can I not just call it ${buildNumber} instead? Ex: com.soebes.examples.j2ee parent 1.2.1-${buildNumber} pom .. ... SNAPSHOT Why do I need to use ${revision}? https://maven.apache.org/maven-ci-friendly.html specifically mentions the above parameters. Why? Thanks, Eric On Thu, May 4, 2017 at 9:40 PM, Justin Georgeson wrote: > Yup :) > > -Original Message- > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] > Sent: Thursday, May 4, 2017 4:52 PM > To: Justin Georgeson ; Maven Users List < > users@maven.apache.org>; i...@soebes.de > Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? > > External Sender: Use caution with links/attachments. > > > > 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 ; 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' 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=RoP1 > >> Y > >> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBG > >> r > >> _pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=by9uci > >> i pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE&e= > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc. > >> o > >&g
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Hi, Interesting. Would something like this be functional then? It seems to work, but I don't know if it is working as expected, or by fluke: com.soebes.examples.j2ee parent ${revision} pom .. 1.2.1-${buildNumber} SNAPSHOT Then at the command line, I can either set the buildNumber in the case of a build: mvn installl -DbuildNumber=12345 This works, but I don't know if I am using this as designed/expected. Thanks, Eric On Sun, May 7, 2017 at 9:59 PM, Bernd Eckenfels wrote: > Hello, > > Only those specific properties are allowed. If I remember correctly the > reason for it is a mixture between it is not possible to support full > property resolving in this stage of the model builder and the intention to > harmonize/restrict to familiarly named usecases. > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a= > blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/ > interpolation/AbstractStringBasedModelInterpolator.java;h= > b47edbe9898b42e25e53afdfb0447ba59183f6a5;hp=cee376f1134db6d78a8bd78ff9f0c7 > 108d86e448;hb=51cc76c32625be2f807dcf2ffbeb085984729b57;hpb= > 181b0215aa1199e152db9d2c08b1a01436547805 > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > From: Eric Benzacar > Sent: Monday, May 8, 2017 3:35:46 AM > To: Maven Users List > Cc: i...@soebes.de > Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? > > I'm confused by something in Karl's blog as well as the instructions for > the flatten-maven-plugin and the actual release notes for Maven 3.5. > > In all the above, they talk about the ${revision}, ${sha1}, ${changelist} > parameters. But what is so special about those particular parameters? Can > I not use any parameter named of my choosing? > > Afterall, the ${revision} value is being set by an environment property, so > can I not just call it ${buildNumber} instead? > > Ex: > > com.soebes.examples.j2ee parent artifactId> > 1.2.1-${buildNumber} pom .. > ... SNAPSHOT > > > Why do I need to use ${revision}? > https://maven.apache.org/maven-ci-friendly.html specifically mentions the > above parameters. Why? > > > Thanks, > > Eric > > > On Thu, May 4, 2017 at 9:40 PM, Justin Georgeson > wrote: > > > Yup :) > > > > -Original Message- > > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] > > Sent: Thursday, May 4, 2017 4:52 PM > > To: Justin Georgeson ; Maven Users List < > > users@maven.apache.org>; i...@soebes.de > > Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? > > > > External Sender: Use caution with links/attachments. > > > > > > > > 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 ; 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
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
On Mon 8 May 2017 at 03:58, Eric Benzacar wrote: > Hi, > > Interesting. Would something like this be functional then? It seems to > work, but I don't know if it is working as expected, or by fluke: > > com.soebes.examples.j2ee parent > ${revision} pom .. > > 1.2.1-${buildNumber} > SNAPSHOT > > > > Then at the command line, I can either set the buildNumber in the case of a > build: > mvn installl -DbuildNumber=12345 > > This works, but I don't know if I am using this as designed/expected. Nope it only *appears to work* If you dig deeper you will see it is not working. The properties *must* be provided either on the CLI or by an extension. At least as I understand it > > Thanks, > > Eric > > > On Sun, May 7, 2017 at 9:59 PM, Bernd Eckenfels > wrote: > > > Hello, > > > > Only those specific properties are allowed. If I remember correctly the > > reason for it is a mixture between it is not possible to support full > > property resolving in this stage of the model builder and the intention > to > > harmonize/restrict to familiarly named usecases. > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a= > > blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/ > > interpolation/AbstractStringBasedModelInterpolator.java;h= > > > b47edbe9898b42e25e53afdfb0447ba59183f6a5;hp=cee376f1134db6d78a8bd78ff9f0c7 > > 108d86e448;hb=51cc76c32625be2f807dcf2ffbeb085984729b57;hpb= > > 181b0215aa1199e152db9d2c08b1a01436547805 > > > > Gruss > > Bernd > > -- > > http://bernd.eckenfels.net > > ____ > > From: Eric Benzacar > > Sent: Monday, May 8, 2017 3:35:46 AM > > To: Maven Users List > > Cc: i...@soebes.de > > Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? > > > > I'm confused by something in Karl's blog as well as the instructions for > > the flatten-maven-plugin and the actual release notes for Maven 3.5. > > > > In all the above, they talk about the ${revision}, ${sha1}, ${changelist} > > parameters. But what is so special about those particular parameters? > Can > > I not use any parameter named of my choosing? > > > > Afterall, the ${revision} value is being set by an environment property, > so > > can I not just call it ${buildNumber} instead? > > > > Ex: > > > > com.soebes.examples.j2ee parent > artifactId> > > 1.2.1-${buildNumber} pom .. > > ... SNAPSHOT > > > > > > Why do I need to use ${revision}? > > https://maven.apache.org/maven-ci-friendly.html specifically mentions > the > > above parameters. Why? > > > > > > Thanks, > > > > Eric > > > > > > On Thu, May 4, 2017 at 9:40 PM, Justin Georgeson > > wrote: > > > > > Yup :) > > > > > > -Original Message- > > > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] > > > Sent: Thursday, May 4, 2017 4:52 PM > > > To: Justin Georgeson ; Maven Users List < > > > users@maven.apache.org>; i...@soebes.de > > > Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now > possible? > > > > > > External Sender: Use caution with links/attachments. > > > > > > > > > > > > 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 ; 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:khmarb
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
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 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 ; 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' 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 Subje
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Hi Karl I think you already made changes to the the plugin, but will file ticket to make it official -D On Thu, May 4, 2017 at 10:09 PM, Karl Heinz Marbaise 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 >> 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 ; 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' 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 -> >>>>
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
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 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 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 ; 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' 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=Ql5uwm
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
t know if I am using this as designed/expected. Nope it only *appears to work* If you dig deeper you will see it is not working. The properties *must* be provided either on the CLI or by an extension. At least as I understand it Thanks, Eric On Sun, May 7, 2017 at 9:59 PM, Bernd Eckenfels wrote: Hello, Only those specific properties are allowed. If I remember correctly the reason for it is a mixture between it is not possible to support full property resolving in this stage of the model builder and the intention to harmonize/restrict to familiarly named usecases. https://git-wip-us.apache.org/repos/asf?p=maven.git;a= blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/ interpolation/AbstractStringBasedModelInterpolator.java;h= b47edbe9898b42e25e53afdfb0447ba59183f6a5;hp=cee376f1134db6d78a8bd78ff9f0c7 108d86e448;hb=51cc76c32625be2f807dcf2ffbeb085984729b57;hpb= 181b0215aa1199e152db9d2c08b1a01436547805 Gruss Bernd -- http://bernd.eckenfels.net From: Eric Benzacar Sent: Monday, May 8, 2017 3:35:46 AM To: Maven Users List Cc: i...@soebes.de Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? I'm confused by something in Karl's blog as well as the instructions for the flatten-maven-plugin and the actual release notes for Maven 3.5. In all the above, they talk about the ${revision}, ${sha1}, ${changelist} parameters. But what is so special about those particular parameters? Can I not use any parameter named of my choosing? Afterall, the ${revision} value is being set by an environment property, so can I not just call it ${buildNumber} instead? Ex: com.soebes.examples.j2ee parent 1.2.1-${buildNumber} pom .. ... SNAPSHOT Why do I need to use ${revision}? https://maven.apache.org/maven-ci-friendly.html specifically mentions the above parameters. Why? Thanks, Eric On Thu, May 4, 2017 at 9:40 PM, Justin Georgeson wrote: Yup :) -Original Message- From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] Sent: Thursday, May 4, 2017 4:52 PM To: Justin Georgeson ; Maven Users List < users@maven.apache.org>; i...@soebes.de Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? External Sender: Use caution with links/attachments. 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 ; 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' 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=RoP1 Y umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=Ql5uwmbofQMW0iErugdCnFgO-CBG r _pt_OzwdxJosG0&m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY&s=by9uci i pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE&e= https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc. o raclecorp.com_artifactory_repo1&d=DwIFaQ&c=PskvixtEUDK7wuWU-tIg6oKuGY B RbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk&m=mQrJ O CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY&s=oPO-3-7EEwzSMAr8-re0YxZdReMu 1 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
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
; > > That is the reason you need the flatten-maven-plugin cause it replace the > propreties in the version tag with it's current version (can do more but > that's a different story) and produce a correct pom file: > > http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"; xmlns=" > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > 4.0.0 > com.soebes.examples.j2ee > parent > 2.0.0-SNAPSHOT > pom > > > Apache License 2.0 > http://www.apache.org/licenses/LICENSE-2.0.txt > repo > > > > which is now consumeable by any kind of tool etc. also Maven itself for > example as a dependency > > I hope it makes this more clear... > > If not please ask/suggest improvements about the docs or what you need to > know > > Kind regards > Karl Heinz Marbaise > > > > > > > > On 08/05/17 14:29, Stephen Connolly wrote: > >> On Mon 8 May 2017 at 03:58, Eric Benzacar wrote: >> >> Hi, >>> >>> Interesting. Would something like this be functional then? It seems to >>> work, but I don't know if it is working as expected, or by fluke: >>> >>> com.soebes.examples.j2ee >>> parent >>> ${revision} pom .. >>> >>> 1.2.1-${buildNumber} >>> SNAPSHOT >>> >>> >>> >>> Then at the command line, I can either set the buildNumber in the case >>> of a >>> build: >>> mvn installl -DbuildNumber=12345 >>> >>> This works, but I don't know if I am using this as designed/expected. >>> >> >> >> Nope it only *appears to work* >> >> If you dig deeper you will see it is not working. >> >> The properties *must* be provided either on the CLI or by an extension. At >> least as I understand it >> >> >> >>> Thanks, >>> >>> Eric >>> >>> >>> On Sun, May 7, 2017 at 9:59 PM, Bernd Eckenfels >>> wrote: >>> >>> Hello, >>>> >>>> Only those specific properties are allowed. If I remember correctly the >>>> reason for it is a mixture between it is not possible to support full >>>> property resolving in this stage of the model builder and the intention >>>> >>> to >>> >>>> harmonize/restrict to familiarly named usecases. >>>> >>>> https://git-wip-us.apache.org/repos/asf?p=maven.git;a= >>>> blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/ >>>> interpolation/AbstractStringBasedModelInterpolator.java;h= >>>> >>>> b47edbe9898b42e25e53afdfb0447ba59183f6a5;hp=cee376f1134db6d7 >>> 8a8bd78ff9f0c7 >>> >>>> 108d86e448;hb=51cc76c32625be2f807dcf2ffbeb085984729b57;hpb= >>>> 181b0215aa1199e152db9d2c08b1a01436547805 >>>> >>>> Gruss >>>> Bernd >>>> -- >>>> http://bernd.eckenfels.net >>>> >>>> From: Eric Benzacar >>>> Sent: Monday, May 8, 2017 3:35:46 AM >>>> To: Maven Users List >>>> Cc: i...@soebes.de >>>> Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? >>>> >>>> I'm confused by something in Karl's blog as well as the instructions for >>>> the flatten-maven-plugin and the actual release notes for Maven 3.5. >>>> >>>> In all the above, they talk about the ${revision}, ${sha1}, >>>> ${changelist} >>>> parameters. But what is so special about those particular parameters? >>>> >>> Can >>> >>>> I not use any parameter named of my choosing? >>>> >>>> Afterall, the ${revision} value is being set by an environment property, >>>> >>> so >>> >>>> can I not just call it ${buildNumber} instead? >>>> >>>> Ex: >>>> >>>> com.soebes.examples.j2ee parent>>> artifactId> >>>> 1.2.1-${buildNumber} pom .. >>>> ... SNAPSHOT >>>> >>>> >>>> Why do I need to use ${revision}? >>>> https://maven.apache.org/maven-ci-friendly.html specifically mentions >>>> >>> the >>> >>>> above parameters. Why? >>>> >>>> >>>> Thanks, >>>> >>>> Eric
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
first glance) > > But now I have given mvn -Drevision=2.0.0 install > > There will produced also files like this: > > $HOME/.m2/repository/com/soebes/examples/j2ee/parent/2.0.0- > SNAPSHOT/parent-2.0.0-SNAPSHOT.pom > > The pom file will look like exactly the same: > > > com.soebes.examples.j2ee > parent > ${revision}${sha1}${changelist} > pom > > > 1.6 > 1.6 > 1.3.1 > -SNAPSHOT > > > > which is obviouly wrong(the same is if you omit the revision, > changelist and sha1 from properties part). > > If you like to consume this pom file it will fail cause this can't be > correctly solve (where is the -Drevision=2.0.0 gone?) > > > That is the reason you need the flatten-maven-plugin cause it replace the > propreties in the version tag with it's current version (can do more but > that's a different story) and produce a correct pom file: > > http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd"; xmlns=" > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > 4.0.0 > com.soebes.examples.j2ee > parent > 2.0.0-SNAPSHOT > pom > > > Apache License 2.0 > http://www.apache.org/licenses/LICENSE-2.0.txt > repo > > > > which is now consumeable by any kind of tool etc. also Maven itself for > example as a dependency > > I hope it makes this more clear... > > If not please ask/suggest improvements about the docs or what you need to > know > > Kind regards > Karl Heinz Marbaise > > > > > > > > On 08/05/17 14:29, Stephen Connolly wrote: > >> On Mon 8 May 2017 at 03:58, Eric Benzacar wrote: >> >> Hi, >>> >>> Interesting. Would something like this be functional then? It seems to >>> work, but I don't know if it is working as expected, or by fluke: >>> >>> com.soebes.examples.j2ee >>> parent >>> ${revision} pom .. >>> >>> 1.2.1-${buildNumber} >>> SNAPSHOT >>> >>> >>> >>> Then at the command line, I can either set the buildNumber in the case >>> of a >>> build: >>> mvn installl -DbuildNumber=12345 >>> >>> This works, but I don't know if I am using this as designed/expected. >>> >> >> >> Nope it only *appears to work* >> >> If you dig deeper you will see it is not working. >> >> The properties *must* be provided either on the CLI or by an extension. At >> least as I understand it >> >> >> >>> Thanks, >>> >>> Eric >>> >>> >>> On Sun, May 7, 2017 at 9:59 PM, Bernd Eckenfels >>> wrote: >>> >>> Hello, >>>> >>>> Only those specific properties are allowed. If I remember correctly the >>>> reason for it is a mixture between it is not possible to support full >>>> property resolving in this stage of the model builder and the intention >>>> >>> to >>> >>>> harmonize/restrict to familiarly named usecases. >>>> >>>> https://git-wip-us.apache.org/repos/asf?p=maven.git;a= >>>> blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/ >>>> interpolation/AbstractStringBasedModelInterpolator.java;h= >>>> >>>> b47edbe9898b42e25e53afdfb0447ba59183f6a5;hp=cee376f1134db6d7 >>> 8a8bd78ff9f0c7 >>> >>>> 108d86e448;hb=51cc76c32625be2f807dcf2ffbeb085984729b57;hpb= >>>> 181b0215aa1199e152db9d2c08b1a01436547805 >>>> >>>> Gruss >>>> Bernd >>>> -- >>>> http://bernd.eckenfels.net >>>> >>>> From: Eric Benzacar >>>> Sent: Monday, May 8, 2017 3:35:46 AM >>>> To: Maven Users List >>>> Cc: i...@soebes.de >>>> Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? >>>> >>>> I'm confused by something in Karl's blog as well as the instructions for >>>> the flatten-maven-plugin and the actual release notes for Maven 3.5. >>>> >>>> In all the above, they talk about the ${revision}, ${sha1}, >>>> ${changelist} >>>> parameters. But what is so special about those particular parameters? >>>> >>> Can >>> >>>> I not use any parameter named of my choosing? >>>> >>>&g
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
You can use the Jenkins environment variable for the build number of a job as a read-only parameter. And I think ${env.BUILD_NUMBER} should also work on the command line. Gruss Bernd -- http://bernd.eckenfels.net From: Eric Benzacar Sent: Wednesday, May 10, 2017 3:32:43 AM To: Maven Users List; i...@soebes.de Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? Thanks for the detailed explanation. A couple of questions come to mind: 1) can the element only contain a variables, or can it be a combination of fixed + variable? for instance: 1.2-${changelist} I see in your examples that it only is a combination of variables with no additional text. 2) How do you handle your CD build definitions, given the need to pass the revision number at build time? Do you end up creating new build definitions for each version, edit the existing build definition for a new version, or is there a way to create a generic build definition that can handle this case? I'm using Jenkins and my biggest annoyance is the need to update/modify my Jenkins job definitions. I could potentially create parameterized build defn, where the user enters the rev #, but that is just going to be error prone. I'm trying to remove as much of the human element from this as possible. Is there a way to design the job definition so that I don't have to specify this information? I realize that I can use the mvn.config file to specify the revision value but what is the advantage of using that and changing that file for each version rather than just changing the pom file itself? Isn't it just shifting the problem from one place to another? Thanks, Eric On Mon, May 8, 2017 at 1:27 PM, Karl Heinz Marbaise wrote: > Hi to all, > > I think it is needed to explain that in more detail (means also to improve > the ci documentation). > > > Let me start with the following: > > You can only use those three names "revision", "changelist" and "sha1" in > a version tag of the pom file cause they are handled special (the > foundation of its handling is given by the explanation of Bernd Eckenfeld > Thanks to Bernd). > > This means in consequence the given part will not work as expected (at the > moment): > > com.soebes.examples.j2ee parent > > ${revision} > pom > > 1.2.1-${buildNumber} > SNAPSHOT > > > > If you like to make combinations you can do it like this for example: > (https://github.com/khmarbaise/javaee/tree/maven350-properties): > > com.soebes.examples.j2ee > parent > ${revision}${sha1}${changelist} > pom > > > 1.6 > 1.6 > 1.3.1 > -SNAPSHOT > > > > or to pickup the previous example which should look like this: > > com.soebes.examples.j2ee parent > > ${revision}${changelist} > pom > > 1.2.1 > -SNAPSHOT > > > So now your build will work as expected. > > If you like to switch to release you simply do that by using the following: > > mvn -Dchangelist= clean package (This will define changelist as empty). > > Or if you like to give a buildNumber from commandline: > > mvn -Dchangelist=-23-SNAPSHOT clean package > > So to make it more convenient you can define the versions like this: > > com.soebes.examples.j2ee > parent > ${revision}${sha1}${changelist} > pom > > > 1.6 > 1.6 > 1.3.1 > -SNAPSHOT > > > > So now I can build via (be carefull with the separator between version and > buildnumber "-"): > > mvn -Dsha1=-123 clean package > > By the above you can now define many combinatations on the command line: > > mvn -Dchangelist= clean package > > This means the command line overwrites the values of the properties which > are defined in the pom file (properties section). > > You can of course remove the properties (properties section) from the pom > file at all and only define the information on command line (works in > Eclipse). But you can also define those things in ".mvn/maven.config" via > the appropriate "-D...". > > > So now lets come to the point about flatten-maven-plugin: > > Assume you are using above proerties in kind of flavour...now you are > using my example( https://github.com/khmarbaise/ > javaee/tree/maven350-properties) without the flatten-maven-plugin in the > build: > > mvn install > > The result of that would be having a folder in your local cache like etc. > where you find a jar file and of course a pom file: (I just picked up two > files as example): > > $HOME/.m2/repository/com/soebes/examples/j2ee/parent/1.3.1- > SNAPSHOT/parent-1.3.1-SNAPSHOT.pom > $HOME//.m2/repository/com/soeb
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
also trace back to my note on this thread, I use buildnumber-m-p for build definition and traceability purpose -D On Tue, May 9, 2017 at 7:46 PM, Bernd Eckenfels wrote: > You can use the Jenkins environment variable for the build number of a job > as a read-only parameter. And I think ${env.BUILD_NUMBER} should also work > on the command line. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > From: Eric Benzacar > Sent: Wednesday, May 10, 2017 3:32:43 AM > To: Maven Users List; i...@soebes.de > Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? > > Thanks for the detailed explanation. > > A couple of questions come to mind: > > 1) can the element only contain a variables, or can it be a > combination of fixed + variable? > for instance: > 1.2-${changelist} > > I see in your examples that it only is a combination of variables with no > additional text. > > > 2) How do you handle your CD build definitions, given the need to pass the > revision number at build time? Do you end up creating new build > definitions for each version, edit the existing build definition for a new > version, or is there a way to create a generic build definition that can > handle this case? > > I'm using Jenkins and my biggest annoyance is the need to update/modify my > Jenkins job definitions. I could potentially create parameterized build > defn, where the user enters the rev #, but that is just going to be error > prone. I'm trying to remove as much of the human element from this as > possible. > > Is there a way to design the job definition so that I don't have to specify > this information? I realize that I can use the mvn.config file to specify > the revision value but what is the advantage of using that and changing > that file for each version rather than just changing the pom file itself? > Isn't it just shifting the problem from one place to another? > > Thanks, > > Eric > > > On Mon, May 8, 2017 at 1:27 PM, Karl Heinz Marbaise > wrote: > > > Hi to all, > > > > I think it is needed to explain that in more detail (means also to > improve > > the ci documentation). > > > > > > Let me start with the following: > > > > You can only use those three names "revision", "changelist" and "sha1" in > > a version tag of the pom file cause they are handled special (the > > foundation of its handling is given by the explanation of Bernd Eckenfeld > > Thanks to Bernd). > > > > This means in consequence the given part will not work as expected (at > the > > moment): > > > > com.soebes.examples.j2ee > parent > > > > ${revision} > > pom > > > > 1.2.1-${buildNumber} > > SNAPSHOT > > > > > > > > If you like to make combinations you can do it like this for example: > > (https://github.com/khmarbaise/javaee/tree/maven350-properties): > > > > com.soebes.examples.j2ee > > parent > > ${revision}${sha1}${changelist} > > pom > > > > > > 1.6 > > 1.6 > > 1.3.1 > > -SNAPSHOT > > > > > > > > or to pickup the previous example which should look like this: > > > > com.soebes.examples.j2ee > parent > > > > ${revision}${changelist} > > pom > > > > 1.2.1 > > -SNAPSHOT > > > > > > So now your build will work as expected. > > > > If you like to switch to release you simply do that by using the > following: > > > > mvn -Dchangelist= clean package (This will define changelist as empty). > > > > Or if you like to give a buildNumber from commandline: > > > > mvn -Dchangelist=-23-SNAPSHOT clean package > > > > So to make it more convenient you can define the versions like this: > > > > com.soebes.examples.j2ee > > parent > > ${revision}${sha1}${changelist} > > pom > > > > > > 1.6 > > 1.6 > > 1.3.1 > > -SNAPSHOT > > > > > > > > So now I can build via (be carefull with the separator between version > and > > buildnumber "-"): > > > > mvn -Dsha1=-123 clean package > > > > By the above you can now define many combinatations on the command line: > > > > mvn -Dchangelist= clean package > > > > This means the command line overwrites the values of the properties which > > are defined in the pom file (properties section). > > > > You can of course remove
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
f you like to consume this pom file it will fail cause this can't be correctly solve (where is the -Drevision=2.0.0 gone?) That is the reason you need the flatten-maven-plugin cause it replace the propreties in the version tag with it's current version (can do more but that's a different story) and produce a correct pom file: http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"; xmlns=" http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> 4.0.0 com.soebes.examples.j2ee parent 2.0.0-SNAPSHOT pom Apache License 2.0 http://www.apache.org/licenses/LICENSE-2.0.txt repo which is now consumeable by any kind of tool etc. also Maven itself for example as a dependency I hope it makes this more clear... If not please ask/suggest improvements about the docs or what you need to know Kind regards Karl Heinz Marbaise On 08/05/17 14:29, Stephen Connolly wrote: On Mon 8 May 2017 at 03:58, Eric Benzacar wrote: Hi, Interesting. Would something like this be functional then? It seems to work, but I don't know if it is working as expected, or by fluke: com.soebes.examples.j2ee parent ${revision} pom .. 1.2.1-${buildNumber} SNAPSHOT Then at the command line, I can either set the buildNumber in the case of a build: mvn installl -DbuildNumber=12345 This works, but I don't know if I am using this as designed/expected. Nope it only *appears to work* If you dig deeper you will see it is not working. The properties *must* be provided either on the CLI or by an extension. At least as I understand it Thanks, Eric On Sun, May 7, 2017 at 9:59 PM, Bernd Eckenfels wrote: Hello, Only those specific properties are allowed. If I remember correctly the reason for it is a mixture between it is not possible to support full property resolving in this stage of the model builder and the intention to harmonize/restrict to familiarly named usecases. https://git-wip-us.apache.org/repos/asf?p=maven.git;a= blobdiff;f=maven-model-builder/src/main/java/org/apache/maven/model/ interpolation/AbstractStringBasedModelInterpolator.java;h= b47edbe9898b42e25e53afdfb0447ba59183f6a5;hp=cee376f1134db6d7 8a8bd78ff9f0c7 108d86e448;hb=51cc76c32625be2f807dcf2ffbeb085984729b57;hpb= 181b0215aa1199e152db9d2c08b1a01436547805 Gruss Bernd -- http://bernd.eckenfels.net From: Eric Benzacar Sent: Monday, May 8, 2017 3:35:46 AM To: Maven Users List Cc: i...@soebes.de Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? I'm confused by something in Karl's blog as well as the instructions for the flatten-maven-plugin and the actual release notes for Maven 3.5. In all the above, they talk about the ${revision}, ${sha1}, ${changelist} parameters. But what is so special about those particular parameters? Can I not use any parameter named of my choosing? Afterall, the ${revision} value is being set by an environment property, so can I not just call it ${buildNumber} instead? Ex: com.soebes.examples.j2ee parent 1.2.1-${buildNumber} pom .. ... SNAPSHOT Why do I need to use ${revision}? https://maven.apache.org/maven-ci-friendly.html specifically mentions the above parameters. Why? Thanks, Eric On Thu, May 4, 2017 at 9:40 PM, Justin Georgeson wrote: Yup :) -Original Message- From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] Sent: Thursday, May 4, 2017 4:52 PM To: Justin Georgeson ; Maven Users List < users@maven.apache.org>; i...@soebes.de Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? External Sender: Use caution with links/attachments. 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 ; 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
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Right... That will give me a build number, but I still need to figure a way to provide the version number to the build. That one had me stumped. Thanks Eric On May 9, 2017 10:46 PM, "Bernd Eckenfels" wrote: > You can use the Jenkins environment variable for the build number of a job > as a read-only parameter. And I think ${env.BUILD_NUMBER} should also work > on the command line. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > From: Eric Benzacar > Sent: Wednesday, May 10, 2017 3:32:43 AM > To: Maven Users List; i...@soebes.de > Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible? > > Thanks for the detailed explanation. > > A couple of questions come to mind: > > 1) can the element only contain a variables, or can it be a > combination of fixed + variable? > for instance: > 1.2-${changelist} > > I see in your examples that it only is a combination of variables with no > additional text. > > > 2) How do you handle your CD build definitions, given the need to pass the > revision number at build time? Do you end up creating new build > definitions for each version, edit the existing build definition for a new > version, or is there a way to create a generic build definition that can > handle this case? > > I'm using Jenkins and my biggest annoyance is the need to update/modify my > Jenkins job definitions. I could potentially create parameterized build > defn, where the user enters the rev #, but that is just going to be error > prone. I'm trying to remove as much of the human element from this as > possible. > > Is there a way to design the job definition so that I don't have to specify > this information? I realize that I can use the mvn.config file to specify > the revision value but what is the advantage of using that and changing > that file for each version rather than just changing the pom file itself? > Isn't it just shifting the problem from one place to another? > > Thanks, > > Eric > > > On Mon, May 8, 2017 at 1:27 PM, Karl Heinz Marbaise > wrote: > > > Hi to all, > > > > I think it is needed to explain that in more detail (means also to > improve > > the ci documentation). > > > > > > Let me start with the following: > > > > You can only use those three names "revision", "changelist" and "sha1" in > > a version tag of the pom file cause they are handled special (the > > foundation of its handling is given by the explanation of Bernd Eckenfeld > > Thanks to Bernd). > > > > This means in consequence the given part will not work as expected (at > the > > moment): > > > > com.soebes.examples.j2ee > parent > > > > ${revision} > > pom > > > > 1.2.1-${buildNumber} > > SNAPSHOT > > > > > > > > If you like to make combinations you can do it like this for example: > > (https://github.com/khmarbaise/javaee/tree/maven350-properties): > > > > com.soebes.examples.j2ee > > parent > > ${revision}${sha1}${changelist} > > pom > > > > > > 1.6 > > 1.6 > > 1.3.1 > > -SNAPSHOT > > > > > > > > or to pickup the previous example which should look like this: > > > > com.soebes.examples.j2ee > parent > > > > ${revision}${changelist} > > pom > > > > 1.2.1 > > -SNAPSHOT > > > > > > So now your build will work as expected. > > > > If you like to switch to release you simply do that by using the > following: > > > > mvn -Dchangelist= clean package (This will define changelist as empty). > > > > Or if you like to give a buildNumber from commandline: > > > > mvn -Dchangelist=-23-SNAPSHOT clean package > > > > So to make it more convenient you can define the versions like this: > > > > com.soebes.examples.j2ee > > parent > > ${revision}${sha1}${changelist} > > pom > > > > > > 1.6 > > 1.6 > > 1.3.1 > > -SNAPSHOT > > > > > > > > So now I can build via (be carefull with the separator between version > and > > buildnumber "-"): > > > > mvn -Dsha1=-123 clean package > > > > By the above you can now define many combinatations on the command line: > > > > mvn -Dchangelist= clean package > > > > This means the command line overwrites the values of the properties which > > are defined in the pom file (properties s
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
t;-"): >>> >>> mvn -Dsha1=-123 clean package >>> >>> By the above you can now define many combinatations on the command line: >>> >>> mvn -Dchangelist= clean package >>> >>> This means the command line overwrites the values of the properties which >>> are defined in the pom file (properties section). >>> >>> You can of course remove the properties (properties section) from the pom >>> file at all and only define the information on command line (works in >>> Eclipse). But you can also define those things in ".mvn/maven.config" via >>> the appropriate "-D...". >>> >>> >>> So now lets come to the point about flatten-maven-plugin: >>> >>> Assume you are using above proerties in kind of flavour...now you are >>> using my example( https://github.com/khmarbaise/ >>> javaee/tree/maven350-properties) without the flatten-maven-plugin in the >>> build: >>> >>> mvn install >>> >>> The result of that would be having a folder in your local cache like etc. >>> where you find a jar file and of course a pom file: (I just picked up two >>> files as example): >>> >>> $HOME/.m2/repository/com/soebes/examples/j2ee/parent/1.3.1- >>> SNAPSHOT/parent-1.3.1-SNAPSHOT.pom >>> $HOME//.m2/repository/com/soebes/examples/j2ee/domain/1.3.1- >>> SNAPSHOT/domain-1.3.1-SNAPSHOT.jar >>> >>> Looks Ok so far? But let us take a look into the pom file: >>> >>> The pom file will look like this: >>> >>> >>> com.soebes.examples.j2ee >>> parent >>> ${revision}${sha1}${changelist} >>> pom >>> >>> >>> 1.6 >>> 1.6 >>> 1.3.1 >>> -SNAPSHOT >>> >>> >>> >>> This looks ok so far (on the first glance) >>> >>> But now I have given mvn -Drevision=2.0.0 install >>> >>> There will produced also files like this: >>> >>> $HOME/.m2/repository/com/soebes/examples/j2ee/parent/2.0.0- >>> SNAPSHOT/parent-2.0.0-SNAPSHOT.pom >>> >>> The pom file will look like exactly the same: >>> >>> >>> com.soebes.examples.j2ee >>> parent >>> ${revision}${sha1}${changelist} >>> pom >>> >>> >>> 1.6 >>> 1.6 >>> 1.3.1 >>> -SNAPSHOT >>> >>> >>> >>> which is obviouly wrong(the same is if you omit the revision, >>> changelist and sha1 from properties part). >>> >>> If you like to consume this pom file it will fail cause this can't be >>> correctly solve (where is the -Drevision=2.0.0 gone?) >>> >>> >>> That is the reason you need the flatten-maven-plugin cause it replace the >>> propreties in the version tag with it's current version (can do more but >>> that's a different story) and produce a correct pom file: >>> >>> http://maven.apache.org/POM/4.0.0 >>> http://maven.apache.org/xsd/maven-4.0.0.xsd"; xmlns=" >>> http://maven.apache.org/POM/4.0.0"; >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> >>> 4.0.0 >>> com.soebes.examples.j2ee >>> parent >>> 2.0.0-SNAPSHOT >>> pom >>> >>> >>> Apache License 2.0 >>> http://www.apache.org/licenses/LICENSE-2.0.txt >>> repo >>> >>> >>> >>> which is now consumeable by any kind of tool etc. also Maven itself for >>> example as a dependency >>> >>> I hope it makes this more clear... >>> >>> If not please ask/suggest improvements about the docs or what you need to >>> know >>> >>> Kind regards >>> Karl Heinz Marbaise >>> >>> >>> >>> >>> >>> >>> >>> On 08/05/17 14:29, Stephen Connolly wrote: >>> >>> On Mon 8 May 2017 at 03:58, Eric Benzacar wrote: >>>> >>>> Hi, >>>> >>>>> >>>>> Interesting. Would something like this be functional then? It seems >>>>> to >>>>> work, but I don't know if it is working as expected, or by fluke: >>>>> >>>>> com.soebes.examples.j2ee >>>>> parent >>>>> ${r
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
I also noticed it takes about a minute for the build to roll after this [INFO] Error stacktraces are turned on. [INFO] Scanning for projects... This is not a good news for local dev build here are 2 time summaries running 250+ modules with skipTests and 4 thread smart builder. The first one does not use ${revision} [INFO] [INFO] Total time: 04:05 min (Wall Clock) [INFO] Finished at: 2017-05-14T19:16:32-07:00 [INFO] Final Memory: 680M/2078M [INFO] [INFO] Total time: 05:56 min (Wall Clock) [INFO] Finished at: 2017-05-14T19:11:00-07:00 [INFO] Final Memory: 1726M/3561M -D
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Just want to share our final outcomes 1. Use snapshot build during development phase 2. At release candidate phase, switch jenkinsfile to release mode * For small projects, use version less Maven continuous deliver friendly, * For large projects, use versions-maven-plugin to change version in all poms at pre-build * Automate the process to tag the final RC (we deploy a build.properties to maven repo at each build, use its info to tag the SCM) Whenever, the startup performance issue for large project is fixed, we will switch to full version less build -Dan On Sun, May 14, 2017 at 7:23 PM, Dan Tran wrote: > I also noticed it takes about a minute for the build to roll after this > > [INFO] Error stacktraces are turned on. > [INFO] Scanning for projects... > > This is not a good news for local dev build > > here are 2 time summaries running 250+ modules with skipTests and 4 thread > smart builder. The first one does not use ${revision} > > [INFO] > > [INFO] Total time: 04:05 min (Wall Clock) > [INFO] Finished at: 2017-05-14T19:16:32-07:00 > [INFO] Final Memory: 680M/2078M > > [INFO] > > [INFO] Total time: 05:56 min (Wall Clock) > [INFO] Finished at: 2017-05-14T19:11:00-07:00 > [INFO] Final Memory: 1726M/3561M > > > -D >
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Dan, Thanks for the update. I'm at the state where I am trying to integrated CD with a large multi-module maven project and trying to get this process running smoothly with Jenkins. For the moment, I'm ok to use a split-Continuous Deployment concept - similar to yours. ie: using SNAPSHOTs for development phase, and anything in a release branch becomes an release candidate. Meaning that any commits into the release/ branch produce a potentially shippable version. But that means that I need poms with version numbers as moving targets (ie: sometimes with SNAPSHOTs, sometimes without). Based on Karl Heinz Marbaise's suggestions, I am planning on building my poms as follows: parent pom: com.benze parent ${revision}${sha1}${changelist} pom 1.3.1 -SNAPSHOT but in my child poms, I'm not sure how to refer to the parent: webapp war com.benze parent ??? ../superpom How do you refer to the parent pom with a constantly (non-defined) moving version? In the past, without using properties like this, I could use the maven-versions-plugin to update the version numbers, but now I don't even see how I can do that. If the revision is defined at the command line in Jenkins (ie: -Drevision=4.5.0), how do I deal with the child poms? If memory serves, the child cannot use properties for the parent version number. How/where to do you specify your semantic version number? I remember you said you use the buildnumber-m-p for the build number, but that how/where/when do you specify the sematic version number? Do you have to manually change it in the poms at RC time? Is it only defined during the build process? Do you have an example of your pom structure and Jenkinsfile pipeline that you can share to help me better grasp how to handle this integration? Thanks, Eric On Fri, Jun 2, 2017 at 5:34 AM, Dan Tran wrote: > Just want to share our final outcomes > > 1. Use snapshot build during development phase > > 2. At release candidate phase, switch jenkinsfile to release mode > > * For small projects, use version less Maven continuous deliver > friendly, > > * For large projects, use versions-maven-plugin to change version in > all poms at pre-build > > * Automate the process to tag the final RC (we deploy a > build.properties to maven repo at each build, use its info to tag the SCM) > > Whenever, the startup performance issue for large project is fixed, we will > switch to full version less build > > -Dan > > On Sun, May 14, 2017 at 7:23 PM, Dan Tran wrote: > > > I also noticed it takes about a minute for the build to roll after this > > > > [INFO] Error stacktraces are turned on. > > [INFO] Scanning for projects... > > > > This is not a good news for local dev build > > > > here are 2 time summaries running 250+ modules with skipTests and 4 > thread > > smart builder. The first one does not use ${revision} > > > > [INFO] > > > > [INFO] Total time: 04:05 min (Wall Clock) > > [INFO] Finished at: 2017-05-14T19:16:32-07:00 > > [INFO] Final Memory: 680M/2078M > > > > [INFO] > > > > [INFO] Total time: 05:56 min (Wall Clock) > > [INFO] Finished at: 2017-05-14T19:11:00-07:00 > > [INFO] Final Memory: 1726M/3561M > > > > > > -D > > >
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Hi Eric i am using the follow at top level parent ${revision} x.y.x-SNAPSHOT In child pom ... ${revision} At jenskins file I have a param releaseVersion by default it is empty if the releaseVersion is not empty, then pass -Drevision-${params.releaseVersion} into maven build This mean i have 3 modes - Default SNAPSHOT build - User can pass in the release version - Auto incremental release build where I update and commit jenkins file to default release version to 'x.y.z-${BUILD_NUMBER}'. I have team that will never use auto incremental release build, and they will manually run the build with a release version of their choice ( mode #2) -Dan On Wed, Jul 26, 2017 at 8:37 PM, Eric Benzacar wrote: > Dan, > > Thanks for the update. I'm at the state where I am trying to integrated CD > with a large multi-module maven project and trying to get this process > running smoothly with Jenkins. For the moment, I'm ok to use a > split-Continuous Deployment concept - similar to yours. ie: using > SNAPSHOTs for development phase, and anything in a release branch becomes > an release candidate. Meaning that any commits into the release/ branch > produce a potentially shippable version. > > But that means that I need poms with version numbers as moving targets (ie: > sometimes with SNAPSHOTs, sometimes without). Based on Karl Heinz > Marbaise's suggestions, I am planning on building my poms as follows: > > parent pom: > > com.benze > parent > ${revision}${sha1}${changelist} > pom > > > 1.3.1 > -SNAPSHOT > > > > > but in my child poms, I'm not sure how to refer to the parent: > > webapp > war > >com.benze >parent > ??? >../superpom > > > > > How do you refer to the parent pom with a constantly (non-defined) moving > version? In the past, without using properties like this, I could use the > maven-versions-plugin to update the version numbers, but now I don't even > see how I can do that. If the revision is defined at the command line in > Jenkins (ie: -Drevision=4.5.0), how do I deal with the child poms? If > memory serves, the child cannot use properties for the parent version > number. > > How/where to do you specify your semantic version number? I remember you > said you use the buildnumber-m-p for the build number, but that > how/where/when do you specify the sematic version number? Do you have to > manually change it in the poms at RC time? Is it only defined during the > build process? > > Do you have an example of your pom structure and Jenkinsfile pipeline that > you can share to help me better grasp how to handle this integration? > > Thanks, > > Eric > > > > On Fri, Jun 2, 2017 at 5:34 AM, Dan Tran wrote: > > > Just want to share our final outcomes > > > > 1. Use snapshot build during development phase > > > > 2. At release candidate phase, switch jenkinsfile to release mode > > > > * For small projects, use version less Maven continuous deliver > > friendly, > > > > * For large projects, use versions-maven-plugin to change version in > > all poms at pre-build > > > > * Automate the process to tag the final RC (we deploy a > > build.properties to maven repo at each build, use its info to tag the > SCM) > > > > Whenever, the startup performance issue for large project is fixed, we > will > > switch to full version less build > > > > -Dan > > > > On Sun, May 14, 2017 at 7:23 PM, Dan Tran wrote: > > > > > I also noticed it takes about a minute for the build to roll after this > > > > > > [INFO] Error stacktraces are turned on. > > > [INFO] Scanning for projects... > > > > > > This is not a good news for local dev build > > > > > > here are 2 time summaries running 250+ modules with skipTests and 4 > > thread > > > smart builder. The first one does not use > ${revision} > > > > > > [INFO] -- > -- > > > > > > [INFO] Total time: 04:05 min (Wall Clock) > > > [INFO] Finished at: 2017-05-14T19:16:32-07:00 > > > [INFO] Final Memory: 680M/2078M > > > > > > [INFO] -- > -- > > > > > > [INFO] Total time: 05:56 min (Wall Clock) > > > [INFO] Finished at: 2017-05-14T19:11:00-07:00 > > > [INFO] Final Memory: 1726M/3561M > > > > > > > > > -D > > > > > >
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Hi Guys, Sorry to reopen a 6 month old thread, but I'm trying to add some more smarts to my stuff, and am failing trying to figure out how to do this. I want to use the buildnumber-maven-plugin:create-metadata goal to generate the metadata build.properties file, which is a great addition to my artifacts. At the same time, I noticed that it contains some useful information that I would want to use in my version number - such as the sha1. But the problem is that I can't figure out how to consume the metadata for my version. Basically, I need to get maven to know the sha1 from my commit. But the metadata file won't be interpolated by maven. And if I use the buildnumber:create goal to get the sha1, I can configure it to be exported as a ${sha1} property. And from everything I've understood, the ONLY properties understood by maven for the tag are ${revision} ${changelist} and ${sha1}. But when I actually run the build all the interpolated version numbers ignore the ${sha1} property as generated by the buildnumber-m-p, even though I bound the create to the validate phase. Although I am not extremely surprised by this, I was sincerely hoping there was some way to make this work. Is there any way at all to be able to leverage what the buildnumber-m-p generates as part of my ? Is the only option to pass the ${sha1} value on command line? A snippet of my pom: test org.project ${revision}${sha1}${changelist} 5.0.0 org.codehaus.mojo buildnumber-maven-plugin 1.4 generate-sha1 validate create sha1 -{0} scmVersion 8 generate-metadata generate-resources create-metadata ${revision}${sha1}${changelist} true true META-INF/build.properties no.scm.config.in.pom Thanks! Eric On Thu, Jul 27, 2017 at 1:46 AM, Dan Tran wrote: > Hi Eric > > > i am using the follow at top level parent > > ${revision} > > > x.y.x-SNAPSHOT > > > In child pom > > > ... > ${revision} > > > > At jenskins file > > I have a param releaseVersion by default it is empty > > if the releaseVersion is not empty, then pass > -Drevision-${params.releaseVersion} into maven build > > > This mean i have 3 modes > >- Default SNAPSHOT build >- User can pass in the release version >- Auto incremental release build where I update and commit jenkins file > to default release version to 'x.y.z-${BUILD_NUMBER}'. > > > I have team that will never use auto incremental release build, and they > will manually run the build with a release version of their choice ( mode > #2) > > > -Dan > > > On Wed, Jul 26, 2017 at 8:37 PM, Eric Benzacar wrote: > > > Dan, > > > > Thanks for the update. I'm at the state where I am trying to integrated > CD > > with a large multi-module maven project and trying to get this process > > running smoothly with Jenkins. For the moment, I'm ok to use a > > split-Continuous Deployment concept - similar to yours. ie: using > > SNAPSHOTs for development phase, and anything in a release branch becomes > > an release candidate. Meaning that any commits into the release/ branch > > produce a potentially shippable version. > > > > But that means that I need poms with version numbers as moving targets > (ie: > > sometimes with SNAPSHOTs, sometimes without). Based on Karl Heinz > > Marbaise's suggestions, I am planning on building my poms as follows: > > > > parent pom: > > > > com.benze > > parent > > ${revision}${sha1}${changelist} > > pom > > > > > > 1.3.1 > > -SNAPSHOT > > > > > > > > > > but in my child poms, I'm not sure how to refer to the parent: > > > > webapp > > war > > > >com.benze > >parent > > ??? > >../superpom > > > > > > > > > > How do you refer to the parent pom with a constantly (non-defined) moving > > version? In the past, without using properties like this, I could use > the > > maven-versions-plugin to update the version numbers, but now I don't even > > see how I can do that. If the revision is defined at the command line in > > Jenkins (ie: -Drevision=4.5.0), how do I deal with the child poms? If > > memory serves, the child cannot use properties for the parent version > > number. > > > > How/where to do you specify your semantic version number? I remember you > > said you use the buildnumber-m-p for the build number, but that > > how/where/when do you specify the sematic version number? Do you have to > > manually change it in the poms at RC time? Is it only defined during the > > build process? > > > > Do you have an example of your pom structure and Jenkinsfile pipeline > that > > you can share to help me better grasp how to handle this integration? > > > > Thanks, > > > > Eric > > > > > > > > On Fri, Jun 2, 2017 at 5:34 AM, Dan Tran wrote: > > > > > Just want to share our final outcomes > > > > > > 1. Use snapshot build during development phase > > > > > > 2. At release candidate phase, switch jenkinsfile to release mode > > > > > > * For small projects, use version
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
I don't think I can help much since I don't use sha1 for revision prop. For my case, I run buildnumber:create-metadata top level only (true) to track SCM info per build and user Jenkins env.BUILD_NUMBER for CD version -Dan On Wed, Nov 8, 2017 at 2:30 PM, Eric Benzacar wrote: > Hi Guys, > > Sorry to reopen a 6 month old thread, but I'm trying to add some more > smarts to my stuff, and am failing trying to figure out how to do this. > > I want to use the buildnumber-maven-plugin:create-metadata goal to > generate the metadata build.properties file, which is a great addition to > my artifacts. At the same time, I noticed that it contains some useful > information that I would want to use in my version number - such as the > sha1. > > But the problem is that I can't figure out how to consume the metadata for > my version. Basically, I need to get maven to know the sha1 from my > commit. But the metadata file won't be interpolated by maven. And if I > use the buildnumber:create goal to get the sha1, I can configure it to be > exported as a ${sha1} property. And from everything I've understood, the > ONLY properties understood by maven for the tag are ${revision} > ${changelist} and ${sha1}. > > But when I actually run the build all the interpolated version numbers > ignore the ${sha1} property as generated by the buildnumber-m-p, even > though I bound the create to the validate phase. > > Although I am not extremely surprised by this, I was sincerely hoping there > was some way to make this work. Is there any way at all to be able to > leverage what the buildnumber-m-p generates as part of my ? Is > the only option to pass the ${sha1} value on command line? > > > A snippet of my pom: > > > test > org.project > ${revision}${sha1}${changelist} > > > 5.0.0 > > > > > > > > org.codehaus.mojo > buildnumber-maven-plugin > 1.4 > > > generate-sha1 > validate > > create > > > > sha1 > > -{0} > > scmVersion > > 8 > > > > generate-metadata > generate-resources > > create-metadata > > > ${revision}${sha1}${changelist} > true > true > META-INF/build.properties > > > > > no.scm.config.in.pom > > > > > > > > > > Thanks! > > Eric > > > On Thu, Jul 27, 2017 at 1:46 AM, Dan Tran wrote: > > > Hi Eric > > > > > > i am using the follow at top level parent > > > > ${revision} > > > > > > x.y.x-SNAPSHOT > > > > > > In child pom > > > > > > ... > > ${revision} > > > > > > > > At jenskins file > > > > I have a param releaseVersion by default it is empty > > > > if the releaseVersion is not empty, then pass > > -Drevision-${params.releaseVersion} into maven build > > > > > > This mean i have 3 modes > > > >- Default SNAPSHOT build > >- User can pass in the release version > >- Auto incremental release build where I update and commit jenkins > file > > to default release version to 'x.y.z-${BUILD_NUMBER}'. > > > > > > I have team that will never use auto incremental release build, and they > > will manually run the build with a release version of their choice ( mode > > #2) > > > > > > -Dan > > > > > > On Wed, Jul 26, 2017 at 8:37 PM, Eric Benzacar wrote: > > > > > Dan, > > > > > > Thanks for the update. I'm at the state where I am trying to > integrated > > CD > > > with a large multi-module maven project and trying to get this process > > > running smoothly with Jenkins. For the moment, I'm ok to use a > > > split-Continuous Deployment concept - similar to yours. ie: using > > > SNAPSHOTs for development phase, and anything in a release branch > becomes > > > an release candidate. Meaning that any commits into the release/ > branch > > > produce a potentially shippable version. > > > > > > But that means that I need poms with version numbers as moving targets > > (ie: > > > sometimes with SNAPSHOTs, sometimes without). Based on Karl Heinz > > > Marbaise's suggestions, I am planning on building my poms as follows: > > > > > > parent pom: > > > > > > com.benze > > > parent > > > ${revision}${sha1}${changelist} > > > pom > > > > > > > > > 1.3.1 > > > -SNAPSHOT > > > > > > > > > > > > > > > but in my child poms, I'm not sure how to refer to the parent: > > > > > > webapp > > > war > > > > > >com.benze > > >parent > > > ??? > > >../superpom > > > > > > > > > > > > > > > How do you refer to the parent pom with a constantly (non-defined) > moving > > > version? In the past, without using properties like this, I could use > > the > > > maven-versions-plugin to update the version numbers, but now I don't > even > > > see how I can do that. If the revision is defined at the command line > in > > > Jenkins (ie: -Drevision=4.5.0), how do I deal with the child poms? If > > > memory serves, the child cannot use properties for the parent version > > > number. > > > > > > How/where to do you specify your semantic version number? I remember > you > > > said you use the buildnumber-m-p for the build nu
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
On Wed, Nov 8, 2017 at 2:31 PM Eric Benzacar wrote: > But when I actually run the build all the interpolated version numbers > ignore the ${sha1} property as generated by the buildnumber-m-p, even > though I bound the create to the validate phase. > [snip] A snippet of my pom: > > > test > org.project > ${revision}${sha1}${changelist} > > > Blind guess: since the buildnumber-maven-plugin is going to set properties using internal machinery, and you've told it the one to set should be named sha1, is it possible that this empty property of the same name is shadowing the one set by the plugin, or that perhaps the plugin won't set it since it's already (effectively) specified? Best, Laird -- https://about.me/lairdnelson
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
I tried removing the empty sha1 declaration as well but that didn't work either. I'm guessing it's due to sequencing - that the interpolation of these special parameters must happen prior to the execution of any plugins, but would love confirmation of that. Additionally would love to know if there is a workaround for this situation. Thanks Eric On Nov 8, 2017 6:35 PM, "Laird Nelson" wrote: > On Wed, Nov 8, 2017 at 2:31 PM Eric Benzacar wrote: > > > But when I actually run the build all the interpolated version numbers > > ignore the ${sha1} property as generated by the buildnumber-m-p, even > > though I bound the create to the validate phase. > > > > [snip] > > A snippet of my pom: > > > > > > test > > org.project > > ${revision}${sha1}${changelist} > > > > > > > > Blind guess: since the buildnumber-maven-plugin is going to set properties > using internal machinery, and you've told it the one to set should be named > sha1, is it possible that this empty property of the same name is shadowing > the one set by the plugin, or that perhaps the plugin won't set it since > it's already (effectively) specified? > > Best, > Laird > -- > https://about.me/lairdnelson >
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
> interpolation of these special parameters must happen prior to the execution of any plugins That's exactly correct. It's why I built https://github.com/pascalgn/properties-maven-extension which is implemented as an extension and runs before any plugins will be executed. Maybe it can help you. 2017-11-09 3:11 GMT+01:00 Eric B : > I tried removing the empty sha1 declaration as well but that didn't work > either. > > I'm guessing it's due to sequencing - that the interpolation of these > special parameters must happen prior to the execution of any plugins, but > would love confirmation of that. Additionally would love to know if there > is a workaround for this situation. > > Thanks > > Eric > > On Nov 8, 2017 6:35 PM, "Laird Nelson" wrote: > > > On Wed, Nov 8, 2017 at 2:31 PM Eric Benzacar wrote: > > > > > But when I actually run the build all the interpolated version numbers > > > ignore the ${sha1} property as generated by the buildnumber-m-p, even > > > though I bound the create to the validate phase. > > > > > > > [snip] > > > > A snippet of my pom: > > > > > > > > > test > > > org.project > > > ${revision}${sha1}${changelist} > > > > > > > > > > > > > Blind guess: since the buildnumber-maven-plugin is going to set > properties > > using internal machinery, and you've told it the one to set should be > named > > sha1, is it possible that this empty property of the same name is > shadowing > > the one set by the plugin, or that perhaps the plugin won't set it since > > it's already (effectively) specified? > > > > Best, > > Laird > > -- > > https://about.me/lairdnelson > > >
Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
Thanks. The extension is precisely what I'm looking for. Eric On Nov 9, 2017 3:47 AM, "Pascal" wrote: > > interpolation of these special parameters must happen prior to the > execution of any plugins > > That's exactly correct. It's why I built > https://github.com/pascalgn/properties-maven-extension which is > implemented > as an extension and runs before any plugins will be executed. > Maybe it can help you. > > 2017-11-09 3:11 GMT+01:00 Eric B : > > > I tried removing the empty sha1 declaration as well but that didn't work > > either. > > > > I'm guessing it's due to sequencing - that the interpolation of these > > special parameters must happen prior to the execution of any plugins, but > > would love confirmation of that. Additionally would love to know if > there > > is a workaround for this situation. > > > > Thanks > > > > Eric > > > > On Nov 8, 2017 6:35 PM, "Laird Nelson" wrote: > > > > > On Wed, Nov 8, 2017 at 2:31 PM Eric Benzacar wrote: > > > > > > > But when I actually run the build all the interpolated version > numbers > > > > ignore the ${sha1} property as generated by the buildnumber-m-p, even > > > > though I bound the create to the validate phase. > > > > > > > > > > [snip] > > > > > > A snippet of my pom: > > > > > > > > > > > > test > > > > org.project > > > > ${revision}${sha1}${changelist} > > > > > > > > > > > > > > > > > > Blind guess: since the buildnumber-maven-plugin is going to set > > properties > > > using internal machinery, and you've told it the one to set should be > > named > > > sha1, is it possible that this empty property of the same name is > > shadowing > > > the one set by the plugin, or that perhaps the plugin won't set it > since > > > it's already (effectively) specified? > > > > > > Best, > > > Laird > > > -- > > > https://about.me/lairdnelson > > > > > >