Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric B]

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
> > >
> >
>

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Pascal]

>  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?

[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?

[Laird Nelson]

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?

[Dan Tran]

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

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric Benzacar]

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 

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

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?

[Eric Benzacar]

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?

[Dan Tran]

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 Tran]

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 Tran]

>>> 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/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 <e...@benzacar.ca> 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
>>>&g

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric B]

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" <e...@zusammenkunft.net> 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 <e...@benzacar.ca>
> 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 <khmarba...@gmx.de>
> 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

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Karl Heinz Marbaise]

rties 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 <e...@benzacar.ca> 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 <e...@zusammenkunft.net>
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 <e...@benzacar.ca>
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 <jgeorge...@lgc.com>
wrote:

Yup :)


-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 4, 2017 4:52 PM
To: Justin Georgeson <jgeorge...@lgc.com>; 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 <users@maven.apache.org>; i...@soebes.de
Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

External Sender: Use caution with links/attachments.



Hard to train developers to break old habits but thanks... :-)



-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; i...@soebes.de
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,

Ah now I see the issue.

If you have a multi module build you should use

mvn -pl mo

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

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 <e...@zusammenkunft.net>
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 <e...@benzacar.ca>
> 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 <khmarba...@gmx.de>
> 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 (prop

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Bernd Eckenfels]

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 <e...@benzacar.ca>
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 <khmarba...@gmx.de>
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.

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric Benzacar]

 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 <e...@benzacar.ca> 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 <e...@zusammenkunft.net>
>>> 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 <e...@benzacar.ca>
>>>> 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?

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

sion=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 <e...@benzacar.ca> 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 <e...@zusammenkunft.net>
>>> 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 <e...@benzacar.ca>
>>>> 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?
>>>>
>>>>
>>>> Th

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Karl Heinz Marbaise]

 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 <e...@zusammenkunft.net>
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 <e...@benzacar.ca>
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 <jgeorge...@lgc.com>
wrote:


Yup :)

-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 4, 2017 4:52 PM
To: Justin Georgeson <jgeorge...@lgc.com>; 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 <users@maven.apache.org>; i...@soebes.de
Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

External Sender: Use caution with links/attachments.



Hard to train developers to break old habits but thanks... :-)



-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; i...@soebes.de
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,

Ah now I see the issue.

If you have a multi module build you should use

mvn -pl moduleToBuild clean install

but from root location and don't change into the module directory

cause

this can't work like this.


Kind regards
Karl Heinz Marbaise

On 04/05/17 22:08, Robert Patrick wrote:

Hi Karl,

If I define the revision property in the top-level POM, I cannot

refer

to it in the module POMs'  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=DwIDaQ=RoP1

Y


umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBG

r


_pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9uci

i pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=


https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.

o


raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGY

B


RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJ

O


CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu

1 5_A4OMXDtdtFyA=  was cached in the local reposito ry, resolution
will not be reattempted until the update interval of repo1 has el

apsed

or updates are 

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Karl Heinz Marbaise]

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 <khmarba...@gmx.de>
wrote:


Hi Dan,

On 05/05/17 02:30, Dan Tran wrote:


is flatten-maven-plugin threadsafe?   if not, we have a problem with large
project where multhreaded build is a must have

maven 3.5 displays a warning on flatten-maven-plugin not thread safe



I need to take a look...can you file in a ticket on flatten-maven-plugin..

Thanks.

Kind regards
Karl Heinz Marbaise



Thanks

-D

On Thu, May 4, 2017 at 2:52 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:

Hi,


On 04/05/17 22:52, Justin Georgeson wrote:

Also I believe the partial reactor switches don't work for Tycho builds.




You mean -pl ..option I suppose?

As far as I know Tycho is handling that at the wrong time of the maven
build and furthermore handles in this relationship some other things
wrong
which results in not working things like this..


Kind regards
Karl Heinz Marbaise


-Original Message-

From: Robert Patrick [mailto:robert.patr...@oracle.com]
Sent: Thursday, May 4, 2017 3:18 PM
To: Maven Users List <users@maven.apache.org>; i...@soebes.de
Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

External Sender: Use caution with links/attachments.



Hard to train developers to break old habits but thanks... :-)



-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; i...@soebes.de
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,

Ah now I see the issue.

If you have a multi module build you should use

mvn -pl moduleToBuild clean install

but from root location and don't change into the module directory cause
this can't work like this.

Kind regards
Karl Heinz Marbaise

On 04/05/17 22:08, Robert Patrick wrote:

Hi Karl,


If I define the revision property in the top-level POM, I cannot refer
to it in the module POMs'  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=DwIDaQ=RoP1Y
umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr
_pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9ucii
pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYB
RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJO
CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu1
5_A4OMXDtdtFyA=  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=DwIDaQ=RoP1YumCXCgaWHvlZYR8
PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJPGvORYVRoH
s2ncTiyaZSJWc3AEyEsUQ=
gException
[ERROR] [Help 2]
https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
onfluence_display_MAVEN_UnresolvableMo=DwIDaQ=RoP1YumCXCgaWHvlZYR8
PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

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 <khmarba...@gmx.de>
wrote:

> Hi Dan,
>
> On 05/05/17 02:30, Dan Tran wrote:
>
>> is flatten-maven-plugin threadsafe?   if not, we have a problem with large
>> project where multhreaded build is a must have
>>
>> maven 3.5 displays a warning on flatten-maven-plugin not thread safe
>>
>
> I need to take a look...can you file in a ticket on flatten-maven-plugin..
>
> Thanks.
>
> Kind regards
> Karl Heinz Marbaise
>
>
>> Thanks
>>
>> -D
>>
>> On Thu, May 4, 2017 at 2:52 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
>> wrote:
>>
>> Hi,
>>>
>>> On 04/05/17 22:52, Justin Georgeson wrote:
>>>
>>> Also I believe the partial reactor switches don't work for Tycho builds.
>>>>
>>>>
>>> You mean -pl ..option I suppose?
>>>
>>> As far as I know Tycho is handling that at the wrong time of the maven
>>> build and furthermore handles in this relationship some other things
>>> wrong
>>> which results in not working things like this..
>>>
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>>
>>> -Original Message-
>>>> From: Robert Patrick [mailto:robert.patr...@oracle.com]
>>>> Sent: Thursday, May 4, 2017 3:18 PM
>>>> To: Maven Users List <users@maven.apache.org>; i...@soebes.de
>>>> Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
>>>>
>>>> External Sender: Use caution with links/attachments.
>>>>
>>>>
>>>>
>>>> Hard to train developers to break old habits but thanks... :-)
>>>>
>>>>
>>>>
>>>> -Original Message-
>>>> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
>>>> Sent: Thursday, May 04, 2017 3:16 PM
>>>> To: Robert Patrick; Maven Users List; i...@soebes.de
>>>> Subject: Re: Continuous Delivery with Maven now possible?
>>>>
>>>> Hi Robert,
>>>>
>>>> Ah now I see the issue.
>>>>
>>>> If you have a multi module build you should use
>>>>
>>>> mvn -pl moduleToBuild clean install
>>>>
>>>> but from root location and don't change into the module directory cause
>>>> this can't work like this.
>>>>
>>>> Kind regards
>>>> Karl Heinz Marbaise
>>>>
>>>> On 04/05/17 22:08, Robert Patrick wrote:
>>>>
>>>> Hi Karl,
>>>>>
>>>>> If I define the revision property in the top-level POM, I cannot refer
>>>>> to it in the module POMs'  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=DwIDaQ=RoP1Y
>>>>> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr
>>>>> _pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9ucii
>>>>> pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
>>>>> raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYB
>>>>> RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJO
>>>>> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu1
>>>>> 5_A4OMXDtdtFyA=  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]
>>>

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Karl Heinz Marbaise]

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 <khmarba...@gmx.de>
wrote:


Hi,

On 04/05/17 22:52, Justin Georgeson wrote:


Also I believe the partial reactor switches don't work for Tycho builds.



You mean -pl ..option I suppose?

As far as I know Tycho is handling that at the wrong time of the maven
build and furthermore handles in this relationship some other things wrong
which results in not working things like this..


Kind regards
Karl Heinz Marbaise



-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com]
Sent: Thursday, May 4, 2017 3:18 PM
To: Maven Users List <users@maven.apache.org>; i...@soebes.de
Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

External Sender: Use caution with links/attachments.



Hard to train developers to break old habits but thanks... :-)



-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; i...@soebes.de
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,

Ah now I see the issue.

If you have a multi module build you should use

mvn -pl moduleToBuild clean install

but from root location and don't change into the module directory cause
this can't work like this.

Kind regards
Karl Heinz Marbaise

On 04/05/17 22:08, Robert Patrick wrote:


Hi Karl,

If I define the revision property in the top-level POM, I cannot refer
to it in the module POMs'  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=DwIDaQ=RoP1Y
umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr
_pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9ucii
pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYB
RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJO
CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu1
5_A4OMXDtdtFyA=  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=DwIDaQ=RoP1YumCXCgaWHvlZYR8
PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJPGvORYVRoH
s2ncTiyaZSJWc3AEyEsUQ=
gException
[ERROR] [Help 2]
https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
onfluence_display_MAVEN_UnresolvableMo=DwIDaQ=RoP1YumCXCgaWHvlZYR8
PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=kjqcy_wD0H5qwfISMGTZrq
XoHWM-jV5GAbTtEvug-bc=
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.

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Stephen Connolly]

On Mon 8 May 2017 at 03:58, Eric Benzacar <e...@benzacar.ca> 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 <e...@zusammenkunft.net>
> 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 <e...@benzacar.ca>
> > 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 <jgeorge...@lgc.com>
> > wrote:
> >
> > > Yup :)
> > >
> > > -Original Message-
> > > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> > > Sent: Thursday, May 4, 2017 4:52 PM
> > > To: Justin Georgeson <jgeorge...@lgc.com>; 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 <users@maven.apache.org>; i...@soebes.de
> > > > Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
> > > >
> > > > External Sender: Use caution with links/attachments.
> > > >
> > > >
> > > >
> > > > Hard to train developers to break old habits but thanks... :-)
> > > >
> > >

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric Benzacar]

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 <e...@zusammenkunft.net>
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 <e...@benzacar.ca>
> 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 <jgeorge...@lgc.com>
> wrote:
>
> > Yup :)
> >
> > -Original Message-
> > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> > Sent: Thursday, May 4, 2017 4:52 PM
> > To: Justin Georgeson <jgeorge...@lgc.com>; 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 <users@maven.apache.org>; i...@soebes.de
> > > Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
> > >
> > > External Sender: Use caution with links/attachments.
> > >
> > >
> > >
> > > Hard to train developers to break old habits but thanks... :-)
> > >
> > >
> > >
> > > -Original Message-
> > > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> > > Sent: Thursday, May 04, 2017 3:16 PM
> > > To: Robert Patrick; Maven Users List; i...@soebes.de
> > > Subject: Re: Continuous Delivery with Maven now possible?
> > >
> > > Hi Robert,
> > >
> > > Ah now I see the issue.
> > >
> > > If you have a multi module build you should use
> > >
> > > mvn -pl moduleToBuild clean install
> > >
> > > but from root location and don't change into the module directory cause
> > this can't work like this.
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > On 04/05/17 22:08, Robert Patrick wrote:
> > >> Hi Karl,
> > >>
> > &

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Bernd Eckenfels]

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 <e...@benzacar.ca>
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 <jgeorge...@lgc.com> wrote:

> Yup :)
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Thursday, May 4, 2017 4:52 PM
> To: Justin Georgeson <jgeorge...@lgc.com>; 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 <users@maven.apache.org>; i...@soebes.de
> > Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
> >
> > External Sender: Use caution with links/attachments.
> >
> >
> >
> > Hard to train developers to break old habits but thanks... :-)
> >
> >
> >
> > -Original Message-----
> > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> > Sent: Thursday, May 04, 2017 3:16 PM
> > To: Robert Patrick; Maven Users List; i...@soebes.de
> > Subject: Re: Continuous Delivery with Maven now possible?
> >
> > Hi Robert,
> >
> > Ah now I see the issue.
> >
> > If you have a multi module build you should use
> >
> > mvn -pl moduleToBuild clean install
> >
> > but from root location and don't change into the module directory cause
> this can't work like this.
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > On 04/05/17 22:08, Robert Patrick wrote:
> >> Hi Karl,
> >>
> >> If I define the revision property in the top-level POM, I cannot refer
> to it in the module POMs'  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=DwIDaQ=RoP1
> >> Y
> >> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBG
> >> r
> >> _pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9uci
> >> i pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifac

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric Benzacar]

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 <jgeorge...@lgc.com> wrote:

> Yup :)
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Thursday, May 4, 2017 4:52 PM
> To: Justin Georgeson <jgeorge...@lgc.com>; 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 <users@maven.apache.org>; i...@soebes.de
> > Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
> >
> > External Sender: Use caution with links/attachments.
> >
> >
> >
> > Hard to train developers to break old habits but thanks... :-)
> >
> >
> >
> > -Original Message-
> > From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> > Sent: Thursday, May 04, 2017 3:16 PM
> > To: Robert Patrick; Maven Users List; i...@soebes.de
> > Subject: Re: Continuous Delivery with Maven now possible?
> >
> > Hi Robert,
> >
> > Ah now I see the issue.
> >
> > If you have a multi module build you should use
> >
> > mvn -pl moduleToBuild clean install
> >
> > but from root location and don't change into the module directory cause
> this can't work like this.
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > On 04/05/17 22:08, Robert Patrick wrote:
> >> Hi Karl,
> >>
> >> If I define the revision property in the top-level POM, I cannot refer
> to it in the module POMs'  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=DwIDaQ=RoP1
> >> Y
> >> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBG
> >> r
> >> _pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9uci
> >> i pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.
> >> o
> >> raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGY
> >> B
> >> RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJ
> >> O
> >> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu
> >> 1 5_A4OMXDtdtFyA=  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

RE: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Justin Georgeson]

Yup :)

-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] 
Sent: Thursday, May 4, 2017 4:52 PM
To: Justin Georgeson <jgeorge...@lgc.com>; 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 <users@maven.apache.org>; i...@soebes.de
> Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
>
> External Sender: Use caution with links/attachments.
>
>
>
> Hard to train developers to break old habits but thanks... :-)
>
>
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Thursday, May 04, 2017 3:16 PM
> To: Robert Patrick; Maven Users List; i...@soebes.de
> Subject: Re: Continuous Delivery with Maven now possible?
>
> Hi Robert,
>
> Ah now I see the issue.
>
> If you have a multi module build you should use
>
> mvn -pl moduleToBuild clean install
>
> but from root location and don't change into the module directory cause this 
> can't work like this.
>
> Kind regards
> Karl Heinz Marbaise
>
> On 04/05/17 22:08, Robert Patrick wrote:
>> Hi Karl,
>>
>> If I define the revision property in the top-level POM, I cannot refer to it 
>> in the module POMs'  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=DwIDaQ=RoP1
>> Y 
>> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBG
>> r 
>> _pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9uci
>> i pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.
>> o 
>> raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGY
>> B 
>> RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJ
>> O
>> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu
>> 1 5_A4OMXDtdtFyA=  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=DwIDaQ=RoP1YumCXCgaWHvlZYR
>> 8 
>> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0
>> & 
>> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJPGvORYVRo
>> H
>> s2ncTiyaZSJWc3AEyEsUQ=
&g

Re: Continuous Delivery with Maven now possible?

[Eric Benzacar]

Hi,

Thanks for the detailed response.  You have a lot of great points in there,
and most of them I agree with (and partially implement already).  As a
CI/CD server, I'm using Jenkins and constantly trying to find better ways
to do things.


> First if you make a release your release process must create a tag in your
> version control with this state of your source code. Furthermore you should
> bake informations like the revision number or sha1 of your version control
> system into your resulting artifacts (configuration of maven-jar, maven-war
> etc.) and a branch name is also helpful which I always encourage
> independent of the usage of this here. This makes traceability more
> easier...
>

I'm not currently tagging my code in my build (shameful - I know).  Sadly,
I haven't figured out the "best" way to create my tags on my build server
and push them to my central repo, without completely polluting my repo (I
would rather not have thousands of tags in my repo).  I suspect if I only
auto-tag my builds for RCs, it will reduce the amount of pollution.  But in
a way, at the end of the day, I really only care about the tag for the code
that actually makes it to Prod.

I am already injecting my commit id, build date, build user, build engine
into the Manifest of my artifact, although that too is being done through a
bit of a workaround.  I don't know if there is a Jenkins plugin that will
do this automatically, but at the moment, I have my org pom defined such
that these properties are added to the manifests for jars, wars and ears.
And I pass the parameters using -Dscm.commitId= etc at the maven
build.  I don't know if there is a better way to do this, and if there is,
I would love to hear about it.



> So based on some Continuous Delivery setups in theses days the created tag
> is not that essential. It is only essential to create a new artifact very
> fast without some run of versions-plugin or bash/script vodoo to only
> change the version number in all pom files and produce one, two or three
> (release plugin) checkins which only contain information about the changed
> versions in pom file nothing more interesting...So if you are working with
> branches the version numbers in pom files are always a pain cause they
> produce always conflicts
>

Agreed - changing version numbers is constantly a royal pain.  Between
merge conflicts and a nuissance to rebuild each time, I would love to avoid
it, if possible, without losing any of the traceability it provides.



> Furthermore based on the above described scenario the question comes into
> my mind: Is the version control the righ tool/location to answer this
> question? In the meantime I tend to say no. The artifact repository (Nexus
> for example) is the better tool/location to answer this question...but this
> a very controversy thing...
>

Agreed again.  I believe that the sources should also be automatically
generated and delivered to Nexus along with the binary.  Not only does this
allow for traceability, it also helps significantly in the debugging
process.  However, it is critical to know in the source control which
versions (ie: which commits) of a source file made it into which
build/release.


> Furthermore if you think about this statement in consequence this means
> you are not allowed to use any version ranges in none of your pom files
> cause this will result in more complicated problems than only not knowing
> the version number from your version control...
>

True.  I don't currently use version ranges (have not really ever seen the
need for it), so it isn't as much of an issue for me.  But I can understand
your point.



> The separation between the "build pom" and the "consumer pom" which is
> implicitly done by this. This means the "build pom" is checked into version
> control but not the resulting "consumer pom" which is only intended for
> consumers of your artifacts and only being available in the destination
> artifact repository which has been built by a technical process. This is
> the same as we compile a Java class cause we only have as a result the
> compiled class file in our jar file but not the source files...
>

Very valid.  However, I also look at it from another perspective.  I like
to be able to check out code at any commit, and be able to know which
"version" it is.  The easiest way to do that is to have a pom with a
version in it that specifies that at that particular snapshot in time, I
was looking at the entire code for version 1.2.3-SNAPSHOT, or
1.2.5.RELEASE.  Have parameters in the version info loses that clarity.



> You have the pom which contains the properties with the versions parts
> like revision,changelist and sha1 and the resulting pom file which is
> installed into the repository (see also flatten-maven-plugin)...or just
> define the property(ies) via command line...
>

I need to look at the flatten-maven-plugin a little more closely.  Is the
pom.xml and pom.properties that maven embeds into the 

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

is flatten-maven-plugin threadsafe?   if not, we have a problem with large
project where multhreaded build is a must have

maven 3.5 displays a warning on flatten-maven-plugin not thread safe

Thanks

-D

On Thu, May 4, 2017 at 2:52 PM, Karl Heinz Marbaise <khmarba...@gmx.de>
wrote:

> Hi,
>
> On 04/05/17 22:52, Justin Georgeson wrote:
>
>> Also I believe the partial reactor switches don't work for Tycho builds.
>>
>
> You mean -pl ..option I suppose?
>
> As far as I know Tycho is handling that at the wrong time of the maven
> build and furthermore handles in this relationship some other things wrong
> which results in not working things like this..
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
>> -Original Message-
>> From: Robert Patrick [mailto:robert.patr...@oracle.com]
>> Sent: Thursday, May 4, 2017 3:18 PM
>> To: Maven Users List <users@maven.apache.org>; i...@soebes.de
>> Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
>>
>> External Sender: Use caution with links/attachments.
>>
>>
>>
>> Hard to train developers to break old habits but thanks... :-)
>>
>>
>>
>> -Original Message-
>> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
>> Sent: Thursday, May 04, 2017 3:16 PM
>> To: Robert Patrick; Maven Users List; i...@soebes.de
>> Subject: Re: Continuous Delivery with Maven now possible?
>>
>> Hi Robert,
>>
>> Ah now I see the issue.
>>
>> If you have a multi module build you should use
>>
>> mvn -pl moduleToBuild clean install
>>
>> but from root location and don't change into the module directory cause
>> this can't work like this.
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> On 04/05/17 22:08, Robert Patrick wrote:
>>
>>> Hi Karl,
>>>
>>> If I define the revision property in the top-level POM, I cannot refer
>>> to it in the module POMs'  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=DwIDaQ=RoP1Y
>>> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr
>>> _pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9ucii
>>> pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
>>> raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYB
>>> RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJO
>>> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu1
>>> 5_A4OMXDtdtFyA=  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=DwID

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Karl Heinz Marbaise]

Hi,

On 04/05/17 22:52, Justin Georgeson wrote:

Also I believe the partial reactor switches don't work for Tycho builds.


You mean -pl ..option I suppose?

As far as I know Tycho is handling that at the wrong time of the maven 
build and furthermore handles in this relationship some other things 
wrong which results in not working things like this..


Kind regards
Karl Heinz Marbaise



-Original Message-
From: Robert Patrick [mailto:robert.patr...@oracle.com]
Sent: Thursday, May 4, 2017 3:18 PM
To: Maven Users List <users@maven.apache.org>; i...@soebes.de
Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

External Sender: Use caution with links/attachments.



Hard to train developers to break old habits but thanks... :-)



-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; i...@soebes.de
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,

Ah now I see the issue.

If you have a multi module build you should use

mvn -pl moduleToBuild clean install

but from root location and don't change into the module directory cause this 
can't work like this.

Kind regards
Karl Heinz Marbaise

On 04/05/17 22:08, Robert Patrick wrote:

Hi Karl,

If I define the revision property in the top-level POM, I cannot refer to it in the 
module POMs'  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=DwIDaQ=RoP1Y
umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr
_pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9ucii
pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYB
RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJO
CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu1
5_A4OMXDtdtFyA=  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=DwIDaQ=RoP1YumCXCgaWHvlZYR8
PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJPGvORYVRoH
s2ncTiyaZSJWc3AEyEsUQ=
gException
[ERROR] [Help 2]
https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
onfluence_display_MAVEN_UnresolvableMo=DwIDaQ=RoP1YumCXCgaWHvlZYR8
PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=kjqcy_wD0H5qwfISMGTZrq
XoHWM-jV5GAbTtEvug-bc=
delException


Did I miss something?

Thanks,
Robert

-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:02 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,


On 04/05/17 21:55, Robert Patrick wrote:


With 3.5, you can now use a variable *but* that variable

 > has to be accessible to the POM prior to finding its  > parent so
the only solution is to move the  >  version number outside the POM
hierarchy and into a -D defined

variable.


Which is not true. You can define the property inside the pom file if you like 
and can overwrite the version via command line (-Drevision=...).



 > While this works, it seems to have some undesirable  > a

RE: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Justin Georgeson]

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 <users@maven.apache.org>; i...@soebes.de
Subject: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

External Sender: Use caution with links/attachments.



Hard to train developers to break old habits but thanks... :-)



-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:16 PM
To: Robert Patrick; Maven Users List; i...@soebes.de
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,

Ah now I see the issue.

If you have a multi module build you should use

mvn -pl moduleToBuild clean install

but from root location and don't change into the module directory cause this 
can't work like this.

Kind regards
Karl Heinz Marbaise

On 04/05/17 22:08, Robert Patrick wrote:
> Hi Karl,
>
> If I define the revision property in the top-level POM, I cannot refer to it 
> in the module POMs'  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=DwIDaQ=RoP1Y
> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr
> _pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9ucii
> pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
> https://urldefense.proofpoint.com/v2/url?u=http-3A__rtifactory-2Dslc.o
> raclecorp.com_artifactory_repo1=DwIFaQ=PskvixtEUDK7wuWU-tIg6oKuGYB
> RbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=mQrJO
> CEKXlLF5VNECH6aqvyAu4kATrZgYUsiitvnfwY=oPO-3-7EEwzSMAr8-re0YxZdReMu1
> 5_A4OMXDtdtFyA=  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=DwIDaQ=RoP1YumCXCgaWHvlZYR8
> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJPGvORYVRoH
> s2ncTiyaZSJWc3AEyEsUQ=
> gException
> [ERROR] [Help 2]
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
> onfluence_display_MAVEN_UnresolvableMo=DwIDaQ=RoP1YumCXCgaWHvlZYR8
> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=kjqcy_wD0H5qwfISMGTZrq
> XoHWM-jV5GAbTtEvug-bc=
> delException
>
>
> Did I miss something?
>
> Thanks,
> Robert
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Thursday, May 04, 2017 3:02 PM
> To: Maven Users List
> Subject: Re: Continuous Delivery with Maven now possible?
>
> Hi Robert,
>
>
> On 04/05/17 21:55, Robert Patrick wrote:
>
>> With 3.5, you can now use a variable *but* that variable
>  > has to be accessible to the POM prior to finding its  > parent so 
> the only solution is to move the  >  version number outside the POM 
> hierarchy and into a -D defined
>> variable.
>
> Which is not true. You can define the property inside the pom file if you 
> like and can overwrite the version vi

RE: Continuous Delivery with Maven now possible?

[Robert Patrick]

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=DwIDaQ=RoP1Y
> umCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr
> _pt_OzwdxJosG0=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=by9ucii
> pxSZU0-Wn16t7grG7a5Djk4ZH9440pGIayRE=
> rtifactory-slc.oraclecorp.com/artifactory/repo1 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=DwIDaQ=RoP1YumCXCgaWHvlZYR8
> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=Gpqh8tXn87EJPGvORYVRoH
> s2ncTiyaZSJWc3AEyEsUQ=
> gException
> [ERROR] [Help 2] 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cwiki.apache.org_c
> onfluence_display_MAVEN_UnresolvableMo=DwIDaQ=RoP1YumCXCgaWHvlZYR8
> PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0&
> m=3nZZwc0AT7pfHVI5gfXOLR0kIk5Pd5HKhazn6HJu6HY=kjqcy_wD0H5qwfISMGTZrq
> XoHWM-jV5GAbTtEvug-bc=
> delException
>
>
> Did I miss something?
>
> Thanks,
> Robert
>
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Thursday, May 04, 2017 3:02 PM
> To: Maven Users List
> Subject: Re: Continuous Delivery with Maven now possible?
>
> Hi Robert,
>
>
> On 04/05/17 21:55, Robert Patrick wrote:
>
>> With 3.5, you can now use a variable *but* that variable
>  > has to be accessible to the POM prior to finding its  > parent so 
> the only solution is to move the  >  version number outside the POM 
> hierarchy and into a -D defined
>> variable.
>
> Which is not true. You can define the property inside the pom file if you 
> like and can overwrite the version via command line (-Drevision=...).
>
>
>
>  > While this works, it seems to have some undesirable  > aspects to 
> it.  In my opinion, it would be better if  > Maven could find a way to 
> resolve this issue  > without resorting to -Ds to specify the  > value 
> of the variable.
>  > I am not sure it is possible but I also worry  > about moving the 
> version number outside the POM...
>>
>> Maybe Maven should consider a mechanism by which the project version number 
>> can be defined in a separate location that is:
>>
>> 1.) Well-known so that all 

Re: Continuous Delivery with Maven now possible?

[Karl Heinz Marbaise]

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 http://a
rtifactory-slc.oraclecorp.com/artifactory/repo1 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] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildin
gException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableMo
delException


Did I miss something?

Thanks,
Robert

-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
Sent: Thursday, May 04, 2017 3:02 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,


On 04/05/17 21:55, Robert Patrick wrote:


With 3.5, you can now use a variable *but* that variable

 > has to be accessible to the POM prior to finding its  > parent so the only 
solution is to move the  >  version number outside the POM hierarchy and into a -D 
defined

variable.


Which is not true. You can define the property inside the pom file if you like 
and can overwrite the version via command line (-Drevision=...).



 > While this works, it seems to have some undesirable
 > aspects to it.  In my opinion, it would be better if
 > Maven could find a way to resolve this issue
 > without resorting to -Ds to specify the
 > value of the variable.
 > I am not sure it is possible but I also worry
 > about moving the version number outside the POM...


Maybe Maven should consider a mechanism by which the project version number can 
be defined in a separate location that is:

1.) Well-known so that all resolution can happen directly by interacting with 
this location directly, without the need to traverse the parent hierarchy
2.) It is part of the project structure so that it can be managed in the 
project's source control system
3.) It cannot be overridden at build time with command-line arguments.
4.) Has a mechanism by which to reference it from all the necessary locations 
within the POMs

Maybe something like an optional .mvn/project.version file and a variable that 
cannot be overridden to refer to it?

-Original Message-
From: Eric Benzacar [mailto:e...@benzacar.ca]
Sent: Thursday, May 04, 2017 12:53 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?

I've read through Karl's blog 
(https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_=DwIFaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk=
2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand 
the approach, there is still one critical issue that bothers me.  I think this 
actually reopens an old thread that circulated on this list a few months ago, 
but it related to the Idempotence of a pom file.

>From my perspective/view a pom file should be idempotent.  That is every 
single build of a given NON-SNAPSHOT pom file should finish with the same build.  
But by moving a release number or version number outside of the p

RE: Continuous Delivery with Maven now possible?

[Robert Patrick]

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 http://a
rtifactory-slc.oraclecorp.com/artifactory/repo1 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] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildin
gException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableMo
delException


Did I miss something?

Thanks,
Robert

-Original Message-
From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] 
Sent: Thursday, May 04, 2017 3:02 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?

Hi Robert,


On 04/05/17 21:55, Robert Patrick wrote:

> With 3.5, you can now use a variable *but* that variable
 > has to be accessible to the POM prior to finding its  > parent so the only 
 > solution is to move the  >  version number outside the POM hierarchy and 
 > into a -D defined
> variable.

Which is not true. You can define the property inside the pom file if you like 
and can overwrite the version via command line (-Drevision=...).



 > While this works, it seems to have some undesirable
 > aspects to it.  In my opinion, it would be better if
 > Maven could find a way to resolve this issue
 > without resorting to -Ds to specify the
 > value of the variable.
 > I am not sure it is possible but I also worry
 > about moving the version number outside the POM...
>
> Maybe Maven should consider a mechanism by which the project version number 
> can be defined in a separate location that is:
>
> 1.) Well-known so that all resolution can happen directly by interacting with 
> this location directly, without the need to traverse the parent hierarchy
> 2.) It is part of the project structure so that it can be managed in the 
> project's source control system
> 3.) It cannot be overridden at build time with command-line arguments.
> 4.) Has a mechanism by which to reference it from all the necessary locations 
> within the POMs
>
> Maybe something like an optional .mvn/project.version file and a variable 
> that cannot be overridden to refer to it?
>
> -Original Message-
> From: Eric Benzacar [mailto:e...@benzacar.ca]
> Sent: Thursday, May 04, 2017 12:53 PM
> To: Maven Users List
> Subject: Re: Continuous Delivery with Maven now possible?
>
> I've read through Karl's blog 
> (https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_=DwIFaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk=
> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand 
> the approach, there is still one critical issue that bothers me.  I think 
> this actually reopens an old thread that circulated on this list a few months 
> ago, but it related to the Idempotence of a pom file.
>
>>From my perspective/view a pom file should be idempotent.  That is every 
>>single build of a given NON-SNAPSHOT pom file should finish with the same 
>>build.  But by moving a release number or version number outside of the pom, 
>>it eliminates this need.  Furthermore, from a traceability perspective, my 
>>source control can no longer show

Re: Continuous Delivery with Maven now possible?

[Karl Heinz Marbaise]

Sorry was to fast with the send button...


On 04/05/17 22:01, Karl Heinz Marbaise wrote:

Hi Robert,


On 04/05/17 21:55, Robert Patrick wrote:


With 3.5, you can now use a variable *but* that variable
has to be accessible to the POM prior to finding its
parent so the only solution is to move the
 version number outside the POM hierarchy and into a -D defined
variable.




Which is not true. You can define the property inside the pom file if
you like and can overwrite the version via command line (-Drevision=...).







While this works, it seems to have some undesirable
aspects to it.  In my opinion, it would be better if
Maven could find a way to resolve this issue
without resorting to -Ds to specify the
value of the variable.
I am not sure it is possible but I also worry
about moving the version number outside the POM...




Maybe Maven should consider a mechanism by which the project version
number can be defined in a separate location that is:

1.) Well-known so that all resolution can happen directly by
interacting with this location directly, without the need to traverse
the parent hierarchy


Can you explain what exactly you mean by this?


2.) It is part of the project structure so that it can be managed in
the project's source control system


You can simply use the .mvn/maven.config file for it...



3.) It cannot be overridden at build time with command-line arguments.


Which contradicts the whole idea of making it simple to change the 
version...




4.) Has a mechanism by which to reference it from all the necessary
locations within the POMs

Maybe something like an optional .mvn/project.version file and a
variable that cannot be overridden to refer to it?


What is the advantage of having a complete different file here? The 
change on the other hand shouldn't be that hard ...



Kind regards
Karl Heinz Marbaise



-Original Message-
From: Eric Benzacar [mailto:e...@benzacar.ca]
Sent: Thursday, May 04, 2017 12:53 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?

I've read through Karl's blog
(https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_=DwIFaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk=

2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
understand the approach, there is still one critical issue that
bothers me.  I think this actually reopens an old thread that
circulated on this list a few months ago, but it related to the
Idempotence of a pom file.


From my perspective/view a pom file should be idempotent.  That is
every single build of a given NON-SNAPSHOT pom file should finish
with the same build.  But by moving a release number or version
number outside of the pom, it eliminates this need.  Furthermore,
from a traceability perspective, my source control can no longer show
me precisely version was being built/developed at any given time.


By leveraging the mvn.config file, I'm a little further down the path,
but none the less, the value can be overridden at build time with a
completely different value.  Consequently, I can still not be 100%
confident that a pom delivered a particular version.

I'm still not 100% sure of the best approach going forward, but I'm
thinking that something like the version-plugin being able to
manipulate a revision property that can then be committed as part of
the pom would be the best of both approaches.  In that way, my
developers can fix the version number, but my build system can
manipulate the revision property.

Does anyone know if there is a plugin that will allow for that?

Thanks,

Eric


On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <t.bro...@gmail.com>
wrote:


How about everybody read their mail?
(see below)

On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrue...@wisc.edu> wrote:


Hi Dan, Karl & everyone,


See Karl's Blog


Link, please?


[…]


On 03/05/17 20:39, Dan Tran wrote:


Hi

I have been experimenting with suggestion from Karl [1] with
small

multi

module maven project.


[…]


[1]
https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou=DwIFaQ
=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0i
ErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
AYSpzB_W99oBqY=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
e=
t-a-version-in-it/






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





Mit freundlichem Gruß
Karl-Heinz Marbaise



Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen   

Re: Continuous Delivery with Maven now possible?

[Karl Heinz Marbaise]

Hi Robert,


On 04/05/17 21:55, Robert Patrick wrote:


With 3.5, you can now use a variable *but* that variable

> has to be accessible to the POM prior to finding its
> parent so the only solution is to move the
>  version number outside the POM hierarchy and into a -D defined

variable.


Which is not true. You can define the property inside the pom file if 
you like and can overwrite the version via command line (-Drevision=...).




> While this works, it seems to have some undesirable
> aspects to it.  In my opinion, it would be better if
> Maven could find a way to resolve this issue
> without resorting to -Ds to specify the
> value of the variable.
> I am not sure it is possible but I also worry
> about moving the version number outside the POM...


Maybe Maven should consider a mechanism by which the project version number can 
be defined in a separate location that is:

1.) Well-known so that all resolution can happen directly by interacting with 
this location directly, without the need to traverse the parent hierarchy
2.) It is part of the project structure so that it can be managed in the 
project's source control system
3.) It cannot be overridden at build time with command-line arguments.
4.) Has a mechanism by which to reference it from all the necessary locations 
within the POMs

Maybe something like an optional .mvn/project.version file and a variable that 
cannot be overridden to refer to it?

-Original Message-
From: Eric Benzacar [mailto:e...@benzacar.ca]
Sent: Thursday, May 04, 2017 12:53 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?

I've read through Karl's blog 
(https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_=DwIFaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk=
2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand 
the approach, there is still one critical issue that bothers me.  I think this 
actually reopens an old thread that circulated on this list a few months ago, 
but it related to the Idempotence of a pom file.


From my perspective/view a pom file should be idempotent.  That is every single 
build of a given NON-SNAPSHOT pom file should finish with the same build.  But 
by moving a release number or version number outside of the pom, it eliminates 
this need.  Furthermore, from a traceability perspective, my source control can 
no longer show me precisely version was being built/developed at any given time.


By leveraging the mvn.config file, I'm a little further down the path, but none 
the less, the value can be overridden at build time with a completely different 
value.  Consequently, I can still not be 100% confident that a pom delivered a 
particular version.

I'm still not 100% sure of the best approach going forward, but I'm thinking 
that something like the version-plugin being able to manipulate a revision 
property that can then be committed as part of the pom would be the best of 
both approaches.  In that way, my developers can fix the version number, but my 
build system can manipulate the revision property.

Does anyone know if there is a plugin that will allow for that?

Thanks,

Eric


On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <t.bro...@gmail.com> wrote:


How about everybody read their mail?
(see below)

On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrue...@wisc.edu> wrote:


Hi Dan, Karl & everyone,


See Karl's Blog


Link, please?


[…]


On 03/05/17 20:39, Dan Tran wrote:


Hi

I have been experimenting with suggestion from Karl [1] with
small

multi

module maven project.


[…]


[1]
https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou=DwIFaQ
=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0i
ErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
AYSpzB_W99oBqY=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
e=
t-a-version-in-it/






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





Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen   http://www.soebes.de

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

Re: Continuous Delivery with Maven now possible?

[Karl Heinz Marbaise]

Hi,

On 04/05/17 19:53, Eric Benzacar wrote:

I've read through Karl's blog (http://blog.soebes.de/blog/
2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
understand the approach, there is still one critical issue that bothers
me.  I think this actually reopens an old thread that circulated on this
list a few months ago, but it related to the Idempotence of a pom file.


From my perspective/view a pom file should be idempotent.  That is every

single build of a given NON-SNAPSHOT pom file should finish with the same
build.  But by moving a release number or version number outside of the
pom, it eliminates this need.  Furthermore, from a traceability
perspective, my source control can no longer show me precisely version was
being built/developed at any given time.

By leveraging the mvn.config file, I'm a little further down the path, but
none the less, the value can be overridden at build time with a completely
different value.  Consequently, I can still not be 100% confident that a
pom delivered a particular version.

I'm still not 100% sure of the best approach going forward, but I'm
thinking that something like the version-plugin being able to manipulate a
revision property that can then be committed as part of the pom would be
the best of both approaches.  In that way, my developers can fix the
version number, but my build system can manipulate the revision property.

Does anyone know if there is a plugin that will allow for that?


Ok let me going into your concerns here.

First we are talking about a NON-SNAPSHOT Build or in other words a 
release build.


If you are using this you should be aware of some parts:

First if you make a release your release process must create a tag in 
your version control with this state of your source code. Furthermore 
you should bake informations like the revision number or sha1 of your 
version control system into your resulting artifacts (configuration of 
maven-jar, maven-war etc.) and a branch name is also helpful which I 
always encourage independent of the usage of this here. This makes 
traceability more easier...


The problem with this approach is that if you simply set the version 
number via properties to a release version and do a simple `mvn deploy` 
which in result produces a release version in my repository.


If I have baked in the above information you can track back from the 
resulting artifact to the state in your version controlwhich from 
point of view is the real needed part...


This will lack the tag which has been created in the previously 
described release setup.


So based on some Continuous Delivery setups in theses days the created 
tag is not that essential. It is only essential to create a new artifact 
very fast without some run of versions-plugin or bash/script vodoo to 
only change the version number in all pom files and produce one, two or 
three (release plugin) checkins which only contain information about the 
changed versions in pom file nothing more interesting...So if you are 
working with branches the version numbers in pom files are always a pain 
cause they produce always conflicts


Furthermore based on the above described scenario the question comes 
into my mind: Is the version control the righ tool/location to answer 
this question? In the meantime I tend to say no. The artifact repository 
(Nexus for example) is the better tool/location to answer this 
question...but this a very controversy thing...



So going to the next point:

> Consequently, I can still not be 100% confident that a
> pom delivered a particular version.

If you make the release setup as I describe you can...The point is you 
need to trust your own setups or implementations for such release 
scenario...


Furthermore if you think about this statement in consequence this means 
you are not allowed to use any version ranges in none of your pom files 
cause this will result in more complicated problems than only not 
knowing the version number from your version control...


And finally a thing which is important to know:

The separation between the "build pom" and the "consumer pom" which is 
implicitly done by this. This means the "build pom" is checked into 
version control but not the resulting "consumer pom" which is only 
intended for consumers of your artifacts and only being available in the 
destination artifact repository which has been built by a technical 
process. This is the same as we compile a Java class cause we only have 
as a result the compiled class file in our jar file but not the source 
files...



You have the pom which contains the properties with the versions parts 
like revision,changelist and sha1 and the resulting pom file which is 
installed into the repository (see also flatten-maven-plugin)...or just 
define the property(ies) via command line...


This is one of the first very small step into the direction to separate 
this explicitly cause If the Maven project will go further this is a 

RE: Continuous Delivery with Maven now possible?

[Robert Patrick]

The problem is that I really want to control the version number for a project 
from a single place.  Ideally, this would be the  element of the 
project's top-level POM.  The problem is that there is no way to do this 
because the module POMs have to declare a parent element that can be resolved 
to find the parent (before they actually find their parent).  Prior to 3.5, you 
were forced down the rabbit hole with using hard-coded parent version numbers 
in the module POM and the release plugin was/is the simplest way (that I have 
found) of handling version number changes across a large project.

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.  While 
this works, it seems to have some undesirable aspects to it.  In my opinion, it 
would be better if Maven could find a way to resolve this issue without 
resorting to -Ds to specify the value of the variable.  I am not sure it is 
possible but I also worry about moving the version number outside the POM...

Maybe Maven should consider a mechanism by which the project version number can 
be defined in a separate location that is:

1.) Well-known so that all resolution can happen directly by interacting with 
this location directly, without the need to traverse the parent hierarchy
2.) It is part of the project structure so that it can be managed in the 
project's source control system
3.) It cannot be overridden at build time with command-line arguments.
4.) Has a mechanism by which to reference it from all the necessary locations 
within the POMs

Maybe something like an optional .mvn/project.version file and a variable that 
cannot be overridden to refer to it? 

-Original Message-
From: Eric Benzacar [mailto:e...@benzacar.ca] 
Sent: Thursday, May 04, 2017 12:53 PM
To: Maven Users List
Subject: Re: Continuous Delivery with Maven now possible?

I've read through Karl's blog 
(https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soebes.de_blog_=DwIFaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0iErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4AYSpzB_W99oBqY=YS5dQgFEyKUuZzQgF6kuQUcPO2kUvZ3-9aUHcY3Kmmk=
2017/04/02/maven-pom-files-without-a-version-in-it/), and while I understand 
the approach, there is still one critical issue that bothers me.  I think this 
actually reopens an old thread that circulated on this list a few months ago, 
but it related to the Idempotence of a pom file.

>From my perspective/view a pom file should be idempotent.  That is every 
>single build of a given NON-SNAPSHOT pom file should finish with the same 
>build.  But by moving a release number or version number outside of the pom, 
>it eliminates this need.  Furthermore, from a traceability perspective, my 
>source control can no longer show me precisely version was being 
>built/developed at any given time.

By leveraging the mvn.config file, I'm a little further down the path, but none 
the less, the value can be overridden at build time with a completely different 
value.  Consequently, I can still not be 100% confident that a pom delivered a 
particular version.

I'm still not 100% sure of the best approach going forward, but I'm thinking 
that something like the version-plugin being able to manipulate a revision 
property that can then be committed as part of the pom would be the best of 
both approaches.  In that way, my developers can fix the version number, but my 
build system can manipulate the revision property.

Does anyone know if there is a plugin that will allow for that?

Thanks,

Eric


On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer <t.bro...@gmail.com> wrote:

> How about everybody read their mail?
> (see below)
>
> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden <ctrue...@wisc.edu> wrote:
>
> > Hi Dan, Karl & everyone,
> >
> > > See Karl's Blog
> >
> > Link, please?
> >
> […]
>
> > > > > On 03/05/17 20:39, Dan Tran wrote:
> > > > >
> > > > >> Hi
> > > > >>
> > > > >> I have been experimenting with suggestion from Karl [1] with 
> > > > >> small
> > > multi
> > > > >> module maven project.
>
> […]
>
> > > > >> [1]
> > > > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__blog.soeb
> > > > >> es.de_blog_2017_04_02_maven-2Dpom-2Dfiles-2Dwithou=DwIFaQ
> > > > >> =RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=Ql5uwmbofQMW0i
> > > > >> ErugdCnFgO-CBGr_pt_OzwdxJosG0=0Ys4DN-HQMZpvVqWFa1z91pnAzKb4
> > > > >> AYSpzB_W99oBqY=RYXyGU3piqrAe7XDXXTuPvbcQH935sduSNhMeYstT8Y&
> > > > >> e=
> > > > >> t-a-version-in-it/
> >
>

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

Re: Continuous Delivery with Maven now possible?

[Dan Tran]

for trace-ability,  i add this to top level pom

 
org.codehaus.mojo
buildnumber-maven-plugin

  
this-has-scm-info-for-tagging-and-tracability-purpose
prepare-package

  create-metadata

false 

  date
  .MM.dd
  true
  
${project.scm.developerConnection}
  

  

  

On Thu, May 4, 2017 at 10:53 AM, Eric Benzacar  wrote:

> I've read through Karl's blog (http://blog.soebes.de/blog/
> 2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
> understand the approach, there is still one critical issue that bothers
> me.  I think this actually reopens an old thread that circulated on this
> list a few months ago, but it related to the Idempotence of a pom file.
>
> From my perspective/view a pom file should be idempotent.  That is every
> single build of a given NON-SNAPSHOT pom file should finish with the same
> build.  But by moving a release number or version number outside of the
> pom, it eliminates this need.  Furthermore, from a traceability
> perspective, my source control can no longer show me precisely version was
> being built/developed at any given time.
>
> By leveraging the mvn.config file, I'm a little further down the path, but
> none the less, the value can be overridden at build time with a completely
> different value.  Consequently, I can still not be 100% confident that a
> pom delivered a particular version.
>
> I'm still not 100% sure of the best approach going forward, but I'm
> thinking that something like the version-plugin being able to manipulate a
> revision property that can then be committed as part of the pom would be
> the best of both approaches.  In that way, my developers can fix the
> version number, but my build system can manipulate the revision property.
>
> Does anyone know if there is a plugin that will allow for that?
>
> Thanks,
>
> Eric
>
>
> On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer  wrote:
>
> > How about everybody read their mail?
> > (see below)
> >
> > On Thu, May 4, 2017 at 6:10 PM Curtis Rueden  wrote:
> >
> > > Hi Dan, Karl & everyone,
> > >
> > > > See Karl's Blog
> > >
> > > Link, please?
> > >
> > […]
> >
> > > > > > On 03/05/17 20:39, Dan Tran wrote:
> > > > > >
> > > > > >> Hi
> > > > > >>
> > > > > >> I have been experimenting with suggestion from Karl [1] with
> small
> > > > multi
> > > > > >> module maven project.
> >
> > […]
> >
> > > > > >> [1]
> > > > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > > > > >> t-a-version-in-it/
> > >
> >
>

Re: Continuous Delivery with Maven now possible?

[Eric Benzacar]

I've read through Karl's blog (http://blog.soebes.de/blog/
2017/04/02/maven-pom-files-without-a-version-in-it/), and while I
understand the approach, there is still one critical issue that bothers
me.  I think this actually reopens an old thread that circulated on this
list a few months ago, but it related to the Idempotence of a pom file.

>From my perspective/view a pom file should be idempotent.  That is every
single build of a given NON-SNAPSHOT pom file should finish with the same
build.  But by moving a release number or version number outside of the
pom, it eliminates this need.  Furthermore, from a traceability
perspective, my source control can no longer show me precisely version was
being built/developed at any given time.

By leveraging the mvn.config file, I'm a little further down the path, but
none the less, the value can be overridden at build time with a completely
different value.  Consequently, I can still not be 100% confident that a
pom delivered a particular version.

I'm still not 100% sure of the best approach going forward, but I'm
thinking that something like the version-plugin being able to manipulate a
revision property that can then be committed as part of the pom would be
the best of both approaches.  In that way, my developers can fix the
version number, but my build system can manipulate the revision property.

Does anyone know if there is a plugin that will allow for that?

Thanks,

Eric


On Thu, May 4, 2017 at 12:40 PM, Thomas Broyer  wrote:

> How about everybody read their mail?
> (see below)
>
> On Thu, May 4, 2017 at 6:10 PM Curtis Rueden  wrote:
>
> > Hi Dan, Karl & everyone,
> >
> > > See Karl's Blog
> >
> > Link, please?
> >
> […]
>
> > > > > On 03/05/17 20:39, Dan Tran wrote:
> > > > >
> > > > >> Hi
> > > > >>
> > > > >> I have been experimenting with suggestion from Karl [1] with small
> > > multi
> > > > >> module maven project.
>
> […]
>
> > > > >> [1]
> > > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > > > >> t-a-version-in-it/
> >
>

Re: Continuous Delivery with Maven now possible?

[Dan Tran]

a couple corrections:

  * for Jenkins freeslyle, one can create a job parameter  similiar to this
format   revision=x.y.x-${BUILD_NUMBER} to override the default maven
version

  * for Jenkins Pipeline, the revision handling is part of  projec's t
Jenkinsfile

The original blog is here http://blog.soebes.de/blog/
2017/04/02/maven-pom-files-without-a-version-in-it/

-D

On Wed, May 3, 2017 at 5:54 PM, Dan Tran  wrote:

> I am able to bring it to production with very small project with few
> modules. Where I hook up jenkins build number with the version
>
>   1.0.0-${env.BUILD_NUMBER}  See Karl's Blog
>
> At the same time,  use buildnumber-m-p to deploy text file with SCM info,
> and finally push to staging repo using Artifactory
>
> Once a build is promoted (GAed), I then remove the rest from staging,  and
> manually tag the build using the recorded SCM info
>
> My next task is a much bigger project with 300+ modules and lots of
> dev/qa.  So it is crucial i dont break their development environments
>
> Thanks
>
> -Dan
>
>
> On Wed, May 3, 2017 at 5:34 PM, Eric B  wrote:
>
>> Hi Karl,
>>
>> Can you provide a little more information how you are doing this? Or do
>> you
>> have a blog about it somewhere? It's something I desperately need to
>> insert
>> into my build pipeline but haven't had the time to work on yet.  So far,
>> the best I've been able to think of is to use a parameter for a build
>> number, have Jenkins assign a build number, pass it to maven, and have the
>> version reflect the build number using the external parameter.  But I
>> really don't like that idea as the version is now dependent on a variable,
>> which I find is contrary to the whole concept.
>>
>> The other option is to have Jenkins took the build number in the pom using
>> the release plugin or the version plugin, commit the new pom, and then
>> build from a newly checked out code.  My issue there is that I'm having
>> Jenkins do a lot of scm manipulations which are more subject to failing
>> (ie: version updates, commit, tag, push, etc).
>>
>> Finally, I'm trying to think of a good way of rolling all this into Nexus
>> staging repos and only promoting a build out of a staging repo once it
>> passes the pre prod environment and is certified for prod.
>>
>> Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
>>
>> Thanks,
>>
>> Eric
>>
>> On May 3, 2017 2:50 PM, "Karl Heinz Marbaise"  wrote:
>>
>> > Hi Dan,
>> >
>> > I'm trying to do something in this direction starting next week...
>> >
>> > Apart from that already tested it with Eclipse Neon without any
>> > issue...(at the moment only test projects with 10-15 modules)...
>> >
>> > But it works at the moment..
>> >
>> > In the meantime I have found one issue which is related to
>> > maven-enforcer-plugin where I already opened an issue for it [1]..
>> >
>> > Kind regards
>> > Karl Heinz
>> >
>> > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
>> >
>> > On 03/05/17 20:39, Dan Tran wrote:
>> >
>> >> Hi
>> >>
>> >> I have been experimenting with suggestion from Karl [1] with small
>> multi
>> >> module maven project.
>> >>
>> >>
>> >> Is there any one actually bring this to production for large scale
>> project
>> >> yet? Love to learn from your experience integration specially with
>> >> Jenkins,
>> >> IDE ( eclipse,  intellij, Netbean)
>> >>
>> >> this allows us to stop using maven-release-plugin
>> >>
>> >> Thanks
>> >>
>> >> -Dan
>> >>
>> >> [1]
>> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> >> t-a-version-in-it/
>> >>
>> >>
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: users-h...@maven.apache.org
>> >
>> >
>>
>
>

Re: Continuous Delivery with Maven now possible?

[Thomas Broyer]

How about everybody read their mail?
(see below)

On Thu, May 4, 2017 at 6:10 PM Curtis Rueden  wrote:

> Hi Dan, Karl & everyone,
>
> > See Karl's Blog
>
> Link, please?
>
[…]

> > > > On 03/05/17 20:39, Dan Tran wrote:
> > > >
> > > >> Hi
> > > >>
> > > >> I have been experimenting with suggestion from Karl [1] with small
> > multi
> > > >> module maven project.

[…]

> > > >> [1]
> > > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > > >> t-a-version-in-it/
>

Re: Continuous Delivery with Maven now possible?

[Curtis Rueden]

Hi Dan, Karl & everyone,

> See Karl's Blog

Link, please?

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden


On Wed, May 3, 2017 at 7:54 PM, Dan Tran  wrote:

> I am able to bring it to production with very small project with few
> modules. Where I hook up jenkins build number with the version
>
>   1.0.0-${env.BUILD_NUMBER}  See Karl's Blog
>
> At the same time,  use buildnumber-m-p to deploy text file with SCM info,
> and finally push to staging repo using Artifactory
>
> Once a build is promoted (GAed), I then remove the rest from staging,  and
> manually tag the build using the recorded SCM info
>
> My next task is a much bigger project with 300+ modules and lots of
> dev/qa.  So it is crucial i dont break their development environments
>
> Thanks
>
> -Dan
>
>
> On Wed, May 3, 2017 at 5:34 PM, Eric B  wrote:
>
> > Hi Karl,
> >
> > Can you provide a little more information how you are doing this? Or do
> you
> > have a blog about it somewhere? It's something I desperately need to
> insert
> > into my build pipeline but haven't had the time to work on yet.  So far,
> > the best I've been able to think of is to use a parameter for a build
> > number, have Jenkins assign a build number, pass it to maven, and have
> the
> > version reflect the build number using the external parameter.  But I
> > really don't like that idea as the version is now dependent on a
> variable,
> > which I find is contrary to the whole concept.
> >
> > The other option is to have Jenkins took the build number in the pom
> using
> > the release plugin or the version plugin, commit the new pom, and then
> > build from a newly checked out code.  My issue there is that I'm having
> > Jenkins do a lot of scm manipulations which are more subject to failing
> > (ie: version updates, commit, tag, push, etc).
> >
> > Finally, I'm trying to think of a good way of rolling all this into Nexus
> > staging repos and only promoting a build out of a staging repo once it
> > passes the pre prod environment and is certified for prod.
> >
> > Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
> >
> > Thanks,
> >
> > Eric
> >
> > On May 3, 2017 2:50 PM, "Karl Heinz Marbaise"  wrote:
> >
> > > Hi Dan,
> > >
> > > I'm trying to do something in this direction starting next week...
> > >
> > > Apart from that already tested it with Eclipse Neon without any
> > > issue...(at the moment only test projects with 10-15 modules)...
> > >
> > > But it works at the moment..
> > >
> > > In the meantime I have found one issue which is related to
> > > maven-enforcer-plugin where I already opened an issue for it [1]..
> > >
> > > Kind regards
> > > Karl Heinz
> > >
> > > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
> > >
> > > On 03/05/17 20:39, Dan Tran wrote:
> > >
> > >> Hi
> > >>
> > >> I have been experimenting with suggestion from Karl [1] with small
> multi
> > >> module maven project.
> > >>
> > >>
> > >> Is there any one actually bring this to production for large scale
> > project
> > >> yet? Love to learn from your experience integration specially with
> > >> Jenkins,
> > >> IDE ( eclipse,  intellij, Netbean)
> > >>
> > >> this allows us to stop using maven-release-plugin
> > >>
> > >> Thanks
> > >>
> > >> -Dan
> > >>
> > >> [1]
> > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > >> t-a-version-in-it/
> > >>
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>

Re: Continuous Delivery with Maven now possible?

[jieryn]

http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/

On Thu, May 4, 2017 at 7:48 AM, Eric B  wrote:
> Hi Dan,
>
> Can you point me to Karl's blog please? I looked for it, but can't seem to
> find it.
>
> Thanks!
>
> Eric
>
> On May 3, 2017 8:56 PM, "Dan Tran"  wrote:
>
>> I am able to bring it to production with very small project with few
>> modules. Where I hook up jenkins build number with the version
>>
>>   1.0.0-${env.BUILD_NUMBER}  See Karl's Blog
>>
>> At the same time,  use buildnumber-m-p to deploy text file with SCM info,
>> and finally push to staging repo using Artifactory
>>
>> Once a build is promoted (GAed), I then remove the rest from staging,  and
>> manually tag the build using the recorded SCM info
>>
>> My next task is a much bigger project with 300+ modules and lots of
>> dev/qa.  So it is crucial i dont break their development environments
>>
>> Thanks
>>
>> -Dan
>>
>>
>> On Wed, May 3, 2017 at 5:34 PM, Eric B  wrote:
>>
>> > Hi Karl,
>> >
>> > Can you provide a little more information how you are doing this? Or do
>> you
>> > have a blog about it somewhere? It's something I desperately need to
>> insert
>> > into my build pipeline but haven't had the time to work on yet.  So far,
>> > the best I've been able to think of is to use a parameter for a build
>> > number, have Jenkins assign a build number, pass it to maven, and have
>> the
>> > version reflect the build number using the external parameter.  But I
>> > really don't like that idea as the version is now dependent on a
>> variable,
>> > which I find is contrary to the whole concept.
>> >
>> > The other option is to have Jenkins took the build number in the pom
>> using
>> > the release plugin or the version plugin, commit the new pom, and then
>> > build from a newly checked out code.  My issue there is that I'm having
>> > Jenkins do a lot of scm manipulations which are more subject to failing
>> > (ie: version updates, commit, tag, push, etc).
>> >
>> > Finally, I'm trying to think of a good way of rolling all this into Nexus
>> > staging repos and only promoting a build out of a staging repo once it
>> > passes the pre prod environment and is certified for prod.
>> >
>> > Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
>> >
>> > Thanks,
>> >
>> > Eric
>> >
>> > On May 3, 2017 2:50 PM, "Karl Heinz Marbaise"  wrote:
>> >
>> > > Hi Dan,
>> > >
>> > > I'm trying to do something in this direction starting next week...
>> > >
>> > > Apart from that already tested it with Eclipse Neon without any
>> > > issue...(at the moment only test projects with 10-15 modules)...
>> > >
>> > > But it works at the moment..
>> > >
>> > > In the meantime I have found one issue which is related to
>> > > maven-enforcer-plugin where I already opened an issue for it [1]..
>> > >
>> > > Kind regards
>> > > Karl Heinz
>> > >
>> > > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
>> > >
>> > > On 03/05/17 20:39, Dan Tran wrote:
>> > >
>> > >> Hi
>> > >>
>> > >> I have been experimenting with suggestion from Karl [1] with small
>> multi
>> > >> module maven project.
>> > >>
>> > >>
>> > >> Is there any one actually bring this to production for large scale
>> > project
>> > >> yet? Love to learn from your experience integration specially with
>> > >> Jenkins,
>> > >> IDE ( eclipse,  intellij, Netbean)
>> > >>
>> > >> this allows us to stop using maven-release-plugin
>> > >>
>> > >> Thanks
>> > >>
>> > >> -Dan
>> > >>
>> > >> [1]
>> > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> > >> t-a-version-in-it/
>> > >>
>> > >>
>> > >
>> > > -
>> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: users-h...@maven.apache.org
>> > >
>> > >
>> >
>>

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

Re: Continuous Delivery with Maven now possible?

[Eric B]

Hi Dan,

Can you point me to Karl's blog please? I looked for it, but can't seem to
find it.

Thanks!

Eric

On May 3, 2017 8:56 PM, "Dan Tran"  wrote:

> I am able to bring it to production with very small project with few
> modules. Where I hook up jenkins build number with the version
>
>   1.0.0-${env.BUILD_NUMBER}  See Karl's Blog
>
> At the same time,  use buildnumber-m-p to deploy text file with SCM info,
> and finally push to staging repo using Artifactory
>
> Once a build is promoted (GAed), I then remove the rest from staging,  and
> manually tag the build using the recorded SCM info
>
> My next task is a much bigger project with 300+ modules and lots of
> dev/qa.  So it is crucial i dont break their development environments
>
> Thanks
>
> -Dan
>
>
> On Wed, May 3, 2017 at 5:34 PM, Eric B  wrote:
>
> > Hi Karl,
> >
> > Can you provide a little more information how you are doing this? Or do
> you
> > have a blog about it somewhere? It's something I desperately need to
> insert
> > into my build pipeline but haven't had the time to work on yet.  So far,
> > the best I've been able to think of is to use a parameter for a build
> > number, have Jenkins assign a build number, pass it to maven, and have
> the
> > version reflect the build number using the external parameter.  But I
> > really don't like that idea as the version is now dependent on a
> variable,
> > which I find is contrary to the whole concept.
> >
> > The other option is to have Jenkins took the build number in the pom
> using
> > the release plugin or the version plugin, commit the new pom, and then
> > build from a newly checked out code.  My issue there is that I'm having
> > Jenkins do a lot of scm manipulations which are more subject to failing
> > (ie: version updates, commit, tag, push, etc).
> >
> > Finally, I'm trying to think of a good way of rolling all this into Nexus
> > staging repos and only promoting a build out of a staging repo once it
> > passes the pre prod environment and is certified for prod.
> >
> > Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
> >
> > Thanks,
> >
> > Eric
> >
> > On May 3, 2017 2:50 PM, "Karl Heinz Marbaise"  wrote:
> >
> > > Hi Dan,
> > >
> > > I'm trying to do something in this direction starting next week...
> > >
> > > Apart from that already tested it with Eclipse Neon without any
> > > issue...(at the moment only test projects with 10-15 modules)...
> > >
> > > But it works at the moment..
> > >
> > > In the meantime I have found one issue which is related to
> > > maven-enforcer-plugin where I already opened an issue for it [1]..
> > >
> > > Kind regards
> > > Karl Heinz
> > >
> > > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
> > >
> > > On 03/05/17 20:39, Dan Tran wrote:
> > >
> > >> Hi
> > >>
> > >> I have been experimenting with suggestion from Karl [1] with small
> multi
> > >> module maven project.
> > >>
> > >>
> > >> Is there any one actually bring this to production for large scale
> > project
> > >> yet? Love to learn from your experience integration specially with
> > >> Jenkins,
> > >> IDE ( eclipse,  intellij, Netbean)
> > >>
> > >> this allows us to stop using maven-release-plugin
> > >>
> > >> Thanks
> > >>
> > >> -Dan
> > >>
> > >> [1]
> > >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> > >> t-a-version-in-it/
> > >>
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>

Re: Continuous Delivery with Maven now possible?

[Dan Tran]

I am able to bring it to production with very small project with few
modules. Where I hook up jenkins build number with the version

  1.0.0-${env.BUILD_NUMBER}  See Karl's Blog

At the same time,  use buildnumber-m-p to deploy text file with SCM info,
and finally push to staging repo using Artifactory

Once a build is promoted (GAed), I then remove the rest from staging,  and
manually tag the build using the recorded SCM info

My next task is a much bigger project with 300+ modules and lots of
dev/qa.  So it is crucial i dont break their development environments

Thanks

-Dan


On Wed, May 3, 2017 at 5:34 PM, Eric B  wrote:

> Hi Karl,
>
> Can you provide a little more information how you are doing this? Or do you
> have a blog about it somewhere? It's something I desperately need to insert
> into my build pipeline but haven't had the time to work on yet.  So far,
> the best I've been able to think of is to use a parameter for a build
> number, have Jenkins assign a build number, pass it to maven, and have the
> version reflect the build number using the external parameter.  But I
> really don't like that idea as the version is now dependent on a variable,
> which I find is contrary to the whole concept.
>
> The other option is to have Jenkins took the build number in the pom using
> the release plugin or the version plugin, commit the new pom, and then
> build from a newly checked out code.  My issue there is that I'm having
> Jenkins do a lot of scm manipulations which are more subject to failing
> (ie: version updates, commit, tag, push, etc).
>
> Finally, I'm trying to think of a good way of rolling all this into Nexus
> staging repos and only promoting a build out of a staging repo once it
> passes the pre prod environment and is certified for prod.
>
> Any ideas, thoughts, feedback and/or tips would be greatly appreciated.
>
> Thanks,
>
> Eric
>
> On May 3, 2017 2:50 PM, "Karl Heinz Marbaise"  wrote:
>
> > Hi Dan,
> >
> > I'm trying to do something in this direction starting next week...
> >
> > Apart from that already tested it with Eclipse Neon without any
> > issue...(at the moment only test projects with 10-15 modules)...
> >
> > But it works at the moment..
> >
> > In the meantime I have found one issue which is related to
> > maven-enforcer-plugin where I already opened an issue for it [1]..
> >
> > Kind regards
> > Karl Heinz
> >
> > [1]: https://issues.apache.org/jira/browse/MENFORCER-268
> >
> > On 03/05/17 20:39, Dan Tran wrote:
> >
> >> Hi
> >>
> >> I have been experimenting with suggestion from Karl [1] with small multi
> >> module maven project.
> >>
> >>
> >> Is there any one actually bring this to production for large scale
> project
> >> yet? Love to learn from your experience integration specially with
> >> Jenkins,
> >> IDE ( eclipse,  intellij, Netbean)
> >>
> >> this allows us to stop using maven-release-plugin
> >>
> >> Thanks
> >>
> >> -Dan
> >>
> >> [1]
> >> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
> >> t-a-version-in-it/
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Continuous Delivery with Maven now possible?

[Eric B]

Hi Karl,

Can you provide a little more information how you are doing this? Or do you
have a blog about it somewhere? It's something I desperately need to insert
into my build pipeline but haven't had the time to work on yet.  So far,
the best I've been able to think of is to use a parameter for a build
number, have Jenkins assign a build number, pass it to maven, and have the
version reflect the build number using the external parameter.  But I
really don't like that idea as the version is now dependent on a variable,
which I find is contrary to the whole concept.

The other option is to have Jenkins took the build number in the pom using
the release plugin or the version plugin, commit the new pom, and then
build from a newly checked out code.  My issue there is that I'm having
Jenkins do a lot of scm manipulations which are more subject to failing
(ie: version updates, commit, tag, push, etc).

Finally, I'm trying to think of a good way of rolling all this into Nexus
staging repos and only promoting a build out of a staging repo once it
passes the pre prod environment and is certified for prod.

Any ideas, thoughts, feedback and/or tips would be greatly appreciated.

Thanks,

Eric

On May 3, 2017 2:50 PM, "Karl Heinz Marbaise"  wrote:

> Hi Dan,
>
> I'm trying to do something in this direction starting next week...
>
> Apart from that already tested it with Eclipse Neon without any
> issue...(at the moment only test projects with 10-15 modules)...
>
> But it works at the moment..
>
> In the meantime I have found one issue which is related to
> maven-enforcer-plugin where I already opened an issue for it [1]..
>
> Kind regards
> Karl Heinz
>
> [1]: https://issues.apache.org/jira/browse/MENFORCER-268
>
> On 03/05/17 20:39, Dan Tran wrote:
>
>> Hi
>>
>> I have been experimenting with suggestion from Karl [1] with small multi
>> module maven project.
>>
>>
>> Is there any one actually bring this to production for large scale project
>> yet? Love to learn from your experience integration specially with
>> Jenkins,
>> IDE ( eclipse,  intellij, Netbean)
>>
>> this allows us to stop using maven-release-plugin
>>
>> Thanks
>>
>> -Dan
>>
>> [1]
>> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> t-a-version-in-it/
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Continuous Delivery with Maven now possible?

[Karl Heinz Marbaise]

Hi Dan,

I'm trying to do something in this direction starting next week...

Apart from that already tested it with Eclipse Neon without any 
issue...(at the moment only test projects with 10-15 modules)...


But it works at the moment..

In the meantime I have found one issue which is related to 
maven-enforcer-plugin where I already opened an issue for it [1]..


Kind regards
Karl Heinz

[1]: https://issues.apache.org/jira/browse/MENFORCER-268

On 03/05/17 20:39, Dan Tran wrote:

Hi

I have been experimenting with suggestion from Karl [1] with small multi
module maven project.


Is there any one actually bring this to production for large scale project
yet? Love to learn from your experience integration specially with Jenkins,
IDE ( eclipse,  intellij, Netbean)

this allows us to stop using maven-release-plugin

Thanks

-Dan

[1]
http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/




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