Re: Maven Cascade Release Plugin

[Andrei Pozolotin]

one more idea for you, totally different answer, hopefully for the same
problem:
https://github.com/barchart/barchart-version-tester/wiki/Version-Policy


 Original Message 
Subject: Re: Maven Cascade Release Plugin
From: daniel brownell 
To: jenkinsci-users@googlegroups.com
Cc: daniel brownell 
Date: Mon 15 Apr 2013 07:28:29 AM CDT
> Ok, it must just be my version then.  I'm running Jenkins 1.480.2
> <http://jenkins-ci.org/>, and the JVM is "JRE 1.6.0 IBM J9 2.4 Linux
> amd64-64".  For some reason, it doesn't want to get the latest from
> the update server. 
>
> I looked at the code, and unfortunately won't be able to write the SVN
> section.  I have no idea what's going on in there. 
> Would you say that to get SVN working, one would have to make a
> superclass for PluginScmGit and PluginScmSvn, replicate the
> functionality of the Git version in the Svn version (using SVNKit, for
> example), and rewrite PluginScm to use the superclass?
>
> Just want to get an idea of what would be required, in case someone
> with more skill is interested in writing it...  is the SCM code
> separated enough that one would only need to work on that section?
>
> Regards,
> Daniel
>
>
> On Monday, 15 April 2013 07:07:10 UTC+2, Andrei Pozolotin wrote:
>
> I verified that install works fine with latest
> debian installer http://pkg.jenkins-ci.org/debian/
> <http://pkg.jenkins-ci.org/debian/>
>
> on ubutnu 12.04
>
>  Original Message 
> Subject: Re: Maven Cascade Release Plugin
> From: daniel brownell  
> To: jenkins...@googlegroups.com 
> Date: Thu 11 Apr 2013 08:55:13 AM CDT
>> Hi Andrei, 
>>
>> I'm interested to try this out.  I asked a question on
>> stackoverflow
>> 
>> <http://stackoverflow.com/questions/15929006/jenkins-maven-release-plugin-cascade-release>,
>> and it seems like this might be what I'm after.
>>
>> How do I get your plug-in to show up in my Plugin Manager view? 
>> I clicked the 'Check Now' button, but no change.  I downloaded
>> the HPI file
>> <http://updates.jenkins-ci.org/download/plugins/maven-release-cascade/>
>> and uploaded it via the Advanced tab, and it just refreshes the
>> screen back to the Updates tab :/  I restarted Jenkins, but no
>> change.  So maybe there's still some issue.
>>
>> Regards,
>> Daniel
>>
>>
>>
>>
>> On Monday, 18 March 2013 20:23:50 UTC+2, Andrei Pozolotin wrote:
>>
>> Hello.
>>
>> This is an invitation to test drive new jenkins plugin
>> 
>> https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin
>> 
>> <https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin>
>>
>> Thank you
>>
>> Andrei.
>>
>> -- 
>> You received this message because you are subscribed to a topic
>> in the Google Groups "Jenkins Users" group.
>> To unsubscribe from this topic, visit
>> 
>> https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en
>> 
>> <https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en>.
>> To unsubscribe from this group and all its topics, send an email
>> to jenkinsci-use...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out
>> <https://groups.google.com/groups/opt_out>.
>>  
>>  
>
> -- 
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Maven Cascade Release Plugin

[Andrei Pozolotin]

or try developer setup
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki/Developer-Manual


 Original Message 
Subject: Re: Maven Cascade Release Plugin
From: daniel brownell 
To: jenkinsci-users@googlegroups.com
Cc: daniel brownell 
Date: Mon 15 Apr 2013 07:28:29 AM CDT
> Ok, it must just be my version then.  I'm running Jenkins 1.480.2
> <http://jenkins-ci.org/>, and the JVM is "JRE 1.6.0 IBM J9 2.4 Linux
> amd64-64".  For some reason, it doesn't want to get the latest from
> the update server. 
>
> I looked at the code, and unfortunately won't be able to write the SVN
> section.  I have no idea what's going on in there. 
> Would you say that to get SVN working, one would have to make a
> superclass for PluginScmGit and PluginScmSvn, replicate the
> functionality of the Git version in the Svn version (using SVNKit, for
> example), and rewrite PluginScm to use the superclass?
>
> Just want to get an idea of what would be required, in case someone
> with more skill is interested in writing it...  is the SCM code
> separated enough that one would only need to work on that section?
>
> Regards,
> Daniel
>
>
> On Monday, 15 April 2013 07:07:10 UTC+2, Andrei Pozolotin wrote:
>
> I verified that install works fine with latest
> debian installer http://pkg.jenkins-ci.org/debian/
> <http://pkg.jenkins-ci.org/debian/>
>
> on ubutnu 12.04
>
>  Original Message 
> Subject: Re: Maven Cascade Release Plugin
> From: daniel brownell  
> To: jenkins...@googlegroups.com 
> Date: Thu 11 Apr 2013 08:55:13 AM CDT
>> Hi Andrei, 
>>
>> I'm interested to try this out.  I asked a question on
>> stackoverflow
>> 
>> <http://stackoverflow.com/questions/15929006/jenkins-maven-release-plugin-cascade-release>,
>> and it seems like this might be what I'm after.
>>
>> How do I get your plug-in to show up in my Plugin Manager view? 
>> I clicked the 'Check Now' button, but no change.  I downloaded
>> the HPI file
>> <http://updates.jenkins-ci.org/download/plugins/maven-release-cascade/>
>> and uploaded it via the Advanced tab, and it just refreshes the
>> screen back to the Updates tab :/  I restarted Jenkins, but no
>> change.  So maybe there's still some issue.
>>
>> Regards,
>> Daniel
>>
>>
>>
>>
>> On Monday, 18 March 2013 20:23:50 UTC+2, Andrei Pozolotin wrote:
>>
>> Hello.
>>
>> This is an invitation to test drive new jenkins plugin
>> 
>> https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin
>> 
>> <https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin>
>>
>> Thank you
>>
>> Andrei.
>>
>> -- 
>> You received this message because you are subscribed to a topic
>> in the Google Groups "Jenkins Users" group.
>> To unsubscribe from this topic, visit
>> 
>> https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en
>> 
>> <https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en>.
>> To unsubscribe from this group and all its topics, send an email
>> to jenkinsci-use...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out
>> <https://groups.google.com/groups/opt_out>.
>>  
>>  
>
> -- 
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Maven Cascade Release Plugin

[Andrei Pozolotin]

Daniel:

 Original Message 
Subject: Re: Maven Cascade Release Plugin
From: daniel brownell 
To: jenkinsci-users@googlegroups.com
Cc: daniel brownell 
Date: Mon 15 Apr 2013 07:28:29 AM CDT
> Ok, it must just be my version then.  I'm running Jenkins 1.480.2
> <http://jenkins-ci.org/>, and the JVM is "JRE 1.6.0 IBM J9 2.4 Linux
> amd64-64".  For some reason, it doesn't want to get the latest from
> the update server. 
sorry cant help you more with this.

I think it has to do with me asking for jenkins 1.503
https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin
I had to move required jenkins version up due to bugs in previous releases.
but I never tried 1.480 specifically - too old for me.

you could try a parallel install:
1) oracle jdk 1.6 or 1.7
2) jenkins at least 1.503

> I looked at the code, and unfortunately won't be able to write the SVN
> section.  I have no idea what's going on in there. 
sorry again :-) it would be easier to understand the code if you get the
plugin working first with git on a test project family.

my scm code essentially was a quick hack - re-implementation of jenkins
git plugin, which is not flexible enough for cascade use case.

> Would you say that to get SVN working, one would have to make a
> superclass for PluginScmGit and PluginScmSvn, replicate the
> functionality of the Git version in the Svn version (using SVNKit, for
> example), and rewrite PluginScm to use the superclass?
yes, you are right. I can re-factor that part.

> Just want to get an idea of what would be required, in case someone
> with more skill is interested in writing it...  
ok.

> is the SCM code separated enough that one would only need to work on
> that section?
yes.

essentially cascade/scm logic is abstracted in 4 places
PluginScm.scmCommit
PluginScm.scmCheckin
PluginScm.scmCheckout
PluginScm.scmUpdate

and layout/scm logic (derive member project scm settings from layout
project scm settings)
https://github.com/barchart/barchart-jenkins-cascade-plugin/blob/master/src/main/java/com/barchart/jenkins/cascade/LayoutLogic.java#L463

>
> Regards,
> Daniel
Andrei.

>
>
> On Monday, 15 April 2013 07:07:10 UTC+2, Andrei Pozolotin wrote:
>
> I verified that install works fine with latest
> debian installer http://pkg.jenkins-ci.org/debian/
> <http://pkg.jenkins-ci.org/debian/>
>
> on ubutnu 12.04
>
>  Original Message 
> Subject: Re: Maven Cascade Release Plugin
> From: daniel brownell  
> To: jenkins...@googlegroups.com 
> Date: Thu 11 Apr 2013 08:55:13 AM CDT
>> Hi Andrei, 
>>
>> I'm interested to try this out.  I asked a question on
>> stackoverflow
>> 
>> <http://stackoverflow.com/questions/15929006/jenkins-maven-release-plugin-cascade-release>,
>> and it seems like this might be what I'm after.
>>
>> How do I get your plug-in to show up in my Plugin Manager view? 
>> I clicked the 'Check Now' button, but no change.  I downloaded
>> the HPI file
>> <http://updates.jenkins-ci.org/download/plugins/maven-release-cascade/>
>> and uploaded it via the Advanced tab, and it just refreshes the
>> screen back to the Updates tab :/  I restarted Jenkins, but no
>> change.  So maybe there's still some issue.
>>
>> Regards,
>> Daniel
>>
>>
>>
>>
>> On Monday, 18 March 2013 20:23:50 UTC+2, Andrei Pozolotin wrote:
>>
>> Hello.
>>
>> This is an invitation to test drive new jenkins plugin
>> 
>> https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin
>> 
>> <https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin>
>>
>> Thank you
>>
>> Andrei.
>>
>> -- 
>> You received this message because you are subscribed to a topic
>> in the Google Groups "Jenkins Users" group.
>> To unsubscribe from this topic, visit
>> 
>> https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en
>> 
>> <https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en>.
>> To unsubscribe from this group and all its topics, send an email
>> to jenkinsci-use...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out
>> <https://groups.google.com/groups/opt_out>.
>>  
>>  
>
> -- 
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
>

Re: Maven Cascade Release Plugin

[Andrei Pozolotin]

I verified that install works fine with latest
debian installer http://pkg.jenkins-ci.org/debian/

on ubutnu 12.04

 Original Message 
Subject: Re: Maven Cascade Release Plugin
From: daniel brownell 
To: jenkinsci-users@googlegroups.com
Date: Thu 11 Apr 2013 08:55:13 AM CDT
> Hi Andrei, 
>
> I'm interested to try this out.  I asked a question on stackoverflow
> <http://stackoverflow.com/questions/15929006/jenkins-maven-release-plugin-cascade-release>,
> and it seems like this might be what I'm after.
>
> How do I get your plug-in to show up in my Plugin Manager view?  I
> clicked the 'Check Now' button, but no change.  I downloaded the HPI
> file
> <http://updates.jenkins-ci.org/download/plugins/maven-release-cascade/> and
> uploaded it via the Advanced tab, and it just refreshes the screen
> back to the Updates tab :/  I restarted Jenkins, but no change.  So
> maybe there's still some issue.
>
> Regards,
> Daniel
>
>
>
>
> On Monday, 18 March 2013 20:23:50 UTC+2, Andrei Pozolotin wrote:
>
> Hello.
>
> This is an invitation to test drive new jenkins plugin
> https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin
> <https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin>
>
> Thank you
>
> Andrei.
>
> -- 
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Maven Cascade Release Plugin

[Andrei Pozolotin]

:-)

do not download it, fork it on github. better yet, drop svn and migrate
to git

 Original Message 
Subject: Re: Maven Cascade Release Plugin
From: daniel brownell 
To: jenkinsci-users@googlegroups.com
Cc: daniel brownell 
Date: Thu 11 Apr 2013 09:28:45 AM CDT
> Oh no :)  I was so excited to be the first. 
>
> Well, I'll DL your code and see if it can be ported to SVN, but I've
> never developed jenkins plug-ins, so I will probably give up once it
> gets difficult.
>
> Thanks for the effort in making the plugin though.  It is definitely
> something that's missing from Jenkins, and I'm surprised it's only
> been developed now.
>
> -Daniel
>
>
>
>
>
>
> On Thursday, 11 April 2013 16:22:53 UTC+2, Andrei Pozolotin wrote:
>
> I just read you SO question.
>
> you have SVN, but I developed / tested this for GIT / github only,
> so after install issue is resolved, it still will not work.
>
> I am not interested in svn, some one else needs to add/test that.
>
>  Original Message 
> Subject: Re: Maven Cascade Release Plugin
> From: daniel brownell  
> To: jenkins...@googlegroups.com 
> Date: Thu 11 Apr 2013 08:55:13 AM CDT
>> Hi Andrei, 
>>
>> I'm interested to try this out.  I asked a question on
>> stackoverflow
>> 
>> <http://stackoverflow.com/questions/15929006/jenkins-maven-release-plugin-cascade-release>,
>> and it seems like this might be what I'm after.
>>
>> How do I get your plug-in to show up in my Plugin Manager view? 
>> I clicked the 'Check Now' button, but no change.  I downloaded
>> the HPI file
>> <http://updates.jenkins-ci.org/download/plugins/maven-release-cascade/>
>> and uploaded it via the Advanced tab, and it just refreshes the
>> screen back to the Updates tab :/  I restarted Jenkins, but no
>> change.  So maybe there's still some issue.
>>
>> Regards,
>> Daniel
>>
>>
>>
>>
>> On Monday, 18 March 2013 20:23:50 UTC+2, Andrei Pozolotin wrote:
>>
>> Hello.
>>
>> This is an invitation to test drive new jenkins plugin
>> 
>> https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin
>> 
>> <https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin>
>>
>> Thank you
>>
>> Andrei.
>>
>> -- 
>> You received this message because you are subscribed to a topic
>> in the Google Groups "Jenkins Users" group.
>> To unsubscribe from this topic, visit
>> 
>> https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en
>> 
>> <https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en>.
>> To unsubscribe from this group and all its topics, send an email
>> to jenkinsci-use...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out
>> <https://groups.google.com/groups/opt_out>.
>>  
>>  
>
> -- 
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Maven Cascade Release Plugin

[Andrei Pozolotin]

I just read you SO question.

you have SVN, but I developed / tested this for GIT / github only,
so after install issue is resolved, it still will not work.

I am not interested in svn, some one else needs to add/test that.

 Original Message 
Subject: Re: Maven Cascade Release Plugin
From: daniel brownell 
To: jenkinsci-users@googlegroups.com
Date: Thu 11 Apr 2013 08:55:13 AM CDT
> Hi Andrei, 
>
> I'm interested to try this out.  I asked a question on stackoverflow
> <http://stackoverflow.com/questions/15929006/jenkins-maven-release-plugin-cascade-release>,
> and it seems like this might be what I'm after.
>
> How do I get your plug-in to show up in my Plugin Manager view?  I
> clicked the 'Check Now' button, but no change.  I downloaded the HPI
> file
> <http://updates.jenkins-ci.org/download/plugins/maven-release-cascade/> and
> uploaded it via the Advanced tab, and it just refreshes the screen
> back to the Updates tab :/  I restarted Jenkins, but no change.  So
> maybe there's still some issue.
>
> Regards,
> Daniel
>
>
>
>
> On Monday, 18 March 2013 20:23:50 UTC+2, Andrei Pozolotin wrote:
>
> Hello.
>
> This is an invitation to test drive new jenkins plugin
> https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin
> <https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin>
>
> Thank you
>
> Andrei.
>
> -- 
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Maven Cascade Release Plugin

[Andrei Pozolotin]

Daniel:

I guess you are my first customer, congratulations :-)

I have no immediate answer, but I will look into this.

What is your os, java/jenkins version?

Thank you,

Andrei 

 Original Message 
Subject: Re: Maven Cascade Release Plugin
From: daniel brownell 
To: jenkinsci-users@googlegroups.com
Date: Thu 11 Apr 2013 08:55:13 AM CDT
> Hi Andrei, 
>
> I'm interested to try this out.  I asked a question on stackoverflow
> <http://stackoverflow.com/questions/15929006/jenkins-maven-release-plugin-cascade-release>,
> and it seems like this might be what I'm after.
>
> How do I get your plug-in to show up in my Plugin Manager view?  I
> clicked the 'Check Now' button, but no change.  I downloaded the HPI
> file
> <http://updates.jenkins-ci.org/download/plugins/maven-release-cascade/> and
> uploaded it via the Advanced tab, and it just refreshes the screen
> back to the Updates tab :/  I restarted Jenkins, but no change.  So
> maybe there's still some issue.
>
> Regards,
> Daniel
>
>
>
>
> On Monday, 18 March 2013 20:23:50 UTC+2, Andrei Pozolotin wrote:
>
> Hello.
>
> This is an invitation to test drive new jenkins plugin
> https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin
> <https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin>
>
> Thank you
>
> Andrei.
>
> -- 
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/V9W3sagC5Zg/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Maven Cascade Release Plugin

[Andrei Pozolotin]

Hello.

This is an invitation to test drive new jenkins plugin
https://wiki.jenkins-ci.org/display/JENKINS/Maven+Cascade+Release+Plugin

Thank you

Andrei.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to better manage cascading releases.

[Andrei Pozolotin]

*Jeff, Jeremy:**
*
update:

1) I released first version of the the plugin.
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki

2) see if you can make sense out of it.

3) please file issues
https://github.com/barchart/barchart-jenkins-cascade-plugin/issues
and improve documentation
https://github.com/barchart/barchart-jenkins-cascade-plugin/wiki

Thank you,

Andrei 

 Original Message 
Subject: How to better manage cascading releases.
From: Andrei Pozolotin 
To: jenkinsci-users@googlegroups.com
Cc: Jeff , Jeremy Jongsma 
Date: Mon 04 Mar 2013 08:26:14 AM CST
> update:
>
> 1) extending maven-release-plugin / jenkins m2release by itself,
> http://maven.apache.org/maven-release/maven-release-plugin/
> https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin
> will not work - need orchestration plugin.
>
> 2) cascade orchestration plugin is here, 30% done:
> https://github.com/barchart/barchart-jenkins-cascade-plugin
>
> 3) proposed target project family repository layout is here
> https://github.com/barchart/barchart-jenkins-tester
>
> feedback & code review is appreciated.
>
>  Original Message 
> Subject: Re: maven-release-plugin : How to better manage cascading
> releases
> From: Jeff 
> To: jenkinsci-users@googlegroups.com
> Date: Thu 28 Feb 2013 12:20:14 PM CST
>> I would guess we would likely want/need both, unless there is a way
>> to tell Maven to "deploy" snapshot or release artifacts only to the
>> local repository.  If it is possible, I don't know how to do that.
>>
>>
>> On Thu, Feb 28, 2013 at 11:14 AM, Jeremy Jongsma > <mailto:jer...@barchart.com>> wrote:
>>
>> I assume he is referring to Git repositories, not Maven
>> repositories, for hosting a set of mock projects with
>> inter-dependencies that are representative of our use cases.
>>
>> Andrei, if you have a repository available, please grant me
>> access and I'll be happy to contribute a use case example.
>>
>> -j
>>
>> On Thu, Feb 28, 2013 at 10:54 AM, Stephen Connolly
>> > <mailto:stephen.alan.conno...@gmail.com>> wrote:
>>
>> 
>> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
>>
>> Please don't host your own maven repositories on an SCM
>>
>>
>> On 28 February 2013 16:50, Jeff > <mailto:predato...@gmail.com>> wrote:
>>
>> Does github have a maven repository?
>>
>>
>> On Thu, Feb 28, 2013 at 7:17 AM, Andrei Pozolotin
>> > <mailto:andrei.pozolo...@gmail.com>> wrote:
>>
>> *Jeff, Keith, Jeremy:*
>>
>> so it seems we have few different use cases in mind
>>     between us.
>>
>> it would probably help if we create 2-3 mock
>> repositories on github
>> to emulate our most interesting use cases.
>>
>> what do you think?
>>
>> Andrei.
>>
>>
>> On Tuesday, February 26, 2013 12:06:16 AM UTC-6,
>> Andrei Pozolotin wrote:
>>
>>   Hello, there!
>>
>> I am curious : "How to better manage
>> cascading releases"
>> for the following use case and what you think
>> about possible solution:
>>
>> #
>>
>>
>> Releasing core bundles and dependent bundles
>>
>> Changing the API of a core bundle for an
>> application requires a rebuild of everything
>> down the line in order to use the new
>> feature. For projects with large numbers of
>> modules (platform, news) this is a very
>> lengthy process of splitting the bundles into
>> dependency phases, then for each phase,
>> releasing a new version of each bundle,
>> updating the next phase's bundles with the
>> newly released versions, and then releasing
>> next phase's bundles, etc, etc. This can be a
>>

How to better manage cascading releases.

[Andrei Pozolotin]

update:

1) extending maven-release-plugin / jenkins m2release by itself,
http://maven.apache.org/maven-release/maven-release-plugin/
https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin
will not work - need orchestration plugin.

2) cascade orchestration plugin is here, 30% done:
https://github.com/barchart/barchart-jenkins-cascade-plugin

3) proposed target project family repository layout is here
https://github.com/barchart/barchart-jenkins-tester

feedback & code review is appreciated.

 Original Message 
Subject: Re: maven-release-plugin : How to better manage cascading releases
From: Jeff 
To: jenkinsci-users@googlegroups.com
Date: Thu 28 Feb 2013 12:20:14 PM CST
> I would guess we would likely want/need both, unless there is a way to
> tell Maven to "deploy" snapshot or release artifacts only to the local
> repository.  If it is possible, I don't know how to do that.
>
>
> On Thu, Feb 28, 2013 at 11:14 AM, Jeremy Jongsma  <mailto:jer...@barchart.com>> wrote:
>
> I assume he is referring to Git repositories, not Maven
> repositories, for hosting a set of mock projects with
> inter-dependencies that are representative of our use cases.
>
> Andrei, if you have a repository available, please grant me access
> and I'll be happy to contribute a use case example.
>
> -j
>
> On Thu, Feb 28, 2013 at 10:54 AM, Stephen Connolly
>  <mailto:stephen.alan.conno...@gmail.com>> wrote:
>
> 
> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
>
> Please don't host your own maven repositories on an SCM
>
>
> On 28 February 2013 16:50, Jeff  <mailto:predato...@gmail.com>> wrote:
>
> Does github have a maven repository?
>
>
> On Thu, Feb 28, 2013 at 7:17 AM, Andrei Pozolotin
>  <mailto:andrei.pozolo...@gmail.com>> wrote:
>
> *Jeff, Keith, Jeremy:*
>
> so it seems we have few different use cases in mind
> between us.
>
> it would probably help if we create 2-3 mock
> repositories on github
> to emulate our most interesting use cases.
>
> what do you think?
>
> Andrei.
>
>
> On Tuesday, February 26, 2013 12:06:16 AM UTC-6,
> Andrei Pozolotin wrote:
>
>   Hello, there!
>
> I am curious : "How to better manage cascading
> releases"
> for the following use case and what you think
> about possible solution:
>
> #
>
>
> Releasing core bundles and dependent bundles
>
> Changing the API of a core bundle for an
> application requires a rebuild of everything
> down the line in order to use the new feature.
> For projects with large numbers of modules
> (platform, news) this is a very lengthy
> process of splitting the bundles into
> dependency phases, then for each phase,
> releasing a new version of each bundle,
> updating the next phase's bundles with the
> newly released versions, and then releasing
> next phase's bundles, etc, etc. This can be a
> multiple hour process with Jenkins, compounded
> by the fact that you can only release one
> sub-project at a time in a Git repository to
> avoid push conflicts causing the build to
> fail. This process occurs much more frequently
> than I would have originally assumed. Right
> now I have a bash script that attempts to
> automate this for news with a combination of
> the maven release and version plugins, but a
> better generic solution would be very welcome.
>
> *Proposal: Modify Jenkins maven release plugin
> with the following behavior:*
>
> 1.
>
> Add a "Cascade release dependent projects"
> checkbox on release page
>
>

Re: maven-release-plugin : How to better manage cascading releases

[Andrei Pozolotin]

Stephen

OK! We won't! :-) Thank you,

Andrei 

 Original Message 
Subject: Re: maven-release-plugin : How to better manage cascading releases
From: Stephen Connolly 
To: jenkinsci-users@googlegroups.com 
Date: Thu 28 Feb 2013 10:54:54 AM CST
> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
>
> Please don't host your own maven repositories on an SCM
>
>
> On 28 February 2013 16:50, Jeff  <mailto:predato...@gmail.com>> wrote:
>
> Does github have a maven repository?
>
>
>     On Thu, Feb 28, 2013 at 7:17 AM, Andrei Pozolotin
> mailto:andrei.pozolo...@gmail.com>>
> wrote:
>
> *Jeff, Keith, Jeremy:*
>
> so it seems we have few different use cases in mind between us.
>
> it would probably help if we create 2-3 mock repositories on
> github
> to emulate our most interesting use cases.
>
> what do you think?
>
>     Andrei.
>
>
> On Tuesday, February 26, 2013 12:06:16 AM UTC-6, Andrei
> Pozolotin wrote:
>
>   Hello, there!
>
> I am curious : "How to better manage cascading releases"
> for the following use case and what you think about
> possible solution:
>
> #
>
>
> Releasing core bundles and dependent bundles
>
> Changing the API of a core bundle for an application
> requires a rebuild of everything down the line in
> order to use the new feature. For projects with large
> numbers of modules (platform, news) this is a very
> lengthy process of splitting the bundles into
> dependency phases, then for each phase, releasing a
> new version of each bundle, updating the next phase's
> bundles with the newly released versions, and then
> releasing next phase's bundles, etc, etc. This can be
> a multiple hour process with Jenkins, compounded by
> the fact that you can only release one sub-project at
> a time in a Git repository to avoid push conflicts
> causing the build to fail. This process occurs much
> more frequently than I would have originally assumed.
> Right now I have a bash script that attempts to
> automate this for news with a combination of the maven
> release and version plugins, but a better generic
> solution would be very welcome.
>
> *Proposal: Modify Jenkins maven release plugin with
> the following behavior:*
>
> 1.
>
> Add a "Cascade release dependent projects"
> checkbox on release page
>
> 2.
>
> After the release completes, look for jobs that
> are explicitly dependent on the pre-release
> snapshot version
>
> 3.
>
> Update these dependent modules with the newly
> release version, and trigger a Maven release on
> them as well
>
> 4.
>
> Failing releases should be skipped, and then
> trigger a build failure at the very end, with
> clearly noted messages as to which sub-tree failed
> so the user can check the logs and manually
> cascade release the subtree
>
> Step c) would need some cycle detection to support
> scenarios where B and C depend on A, but C also
> depends on B - both A and B would have to be released
> before C could be released.
>
> #
>
> Thank you,
>
> Andrei
>
> -- 
> You received this message because you are subscribed to the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to
> jenkinsci-users+unsubscr...@googlegroups.com
> <mailto:jenkinsci-users%2bunsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
>
>
>
>
> -- 
> Jeff Vincent
>
> See my LinkedIn profile at:
> http://

Re: maven-release-plugin : How to better manage cascading releases

[Andrei Pozolotin]

*Jeff, Jeremy:**
*
you are right, we need both.

1) here is git repo for project layout use cases
https://github.com/barchart/barchart-jenkins-tester

2) for maven, I assumed we can use our respective private repository
"distribution" settings as defined by our settings.xml.

for example, when you run theses tests

https://github.com/barchart/barchart-jenkins-m2release-plugin/tree/master/src/test/java/org/jvnet/hudson/plugins/m2release

they build and fire up your local jenkins with plugin inside, which
will use your local .m2/settings.xml

alternatively, we can setup shared maven repo on Amazon S3 or
CloudBees@DEV

Thank you,

Andrei 

 Original Message 
Subject: Re: maven-release-plugin : How to better manage cascading releases
From: Jeff 
To: jenkinsci-users@googlegroups.com
Date: Thu 28 Feb 2013 12:20:14 PM CST
> I would guess we would likely want/need both, unless there is a way to
> tell Maven to "deploy" snapshot or release artifacts only to the local
> repository.  If it is possible, I don't know how to do that.
>
>
> On Thu, Feb 28, 2013 at 11:14 AM, Jeremy Jongsma  <mailto:jer...@barchart.com>> wrote:
>
> I assume he is referring to Git repositories, not Maven
> repositories, for hosting a set of mock projects with
> inter-dependencies that are representative of our use cases.
>
> Andrei, if you have a repository available, please grant me access
> and I'll be happy to contribute a use case example.
>
> -j
>
> On Thu, Feb 28, 2013 at 10:54 AM, Stephen Connolly
>  <mailto:stephen.alan.conno...@gmail.com>> wrote:
>
> 
> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
>
> Please don't host your own maven repositories on an SCM
>
>
> On 28 February 2013 16:50, Jeff  <mailto:predato...@gmail.com>> wrote:
>
> Does github have a maven repository?
>
>
> On Thu, Feb 28, 2013 at 7:17 AM, Andrei Pozolotin
>  <mailto:andrei.pozolo...@gmail.com>> wrote:
>
> *Jeff, Keith, Jeremy:*
>
> so it seems we have few different use cases in mind
> between us.
>
> it would probably help if we create 2-3 mock
> repositories on github
> to emulate our most interesting use cases.
>
> what do you think?
>
> Andrei.
>
>
> On Tuesday, February 26, 2013 12:06:16 AM UTC-6,
> Andrei Pozolotin wrote:
>
>   Hello, there!
>
> I am curious : "How to better manage cascading
> releases"
> for the following use case and what you think
> about possible solution:
>
> #
>
>
> Releasing core bundles and dependent bundles
>
> Changing the API of a core bundle for an
> application requires a rebuild of everything
> down the line in order to use the new feature.
> For projects with large numbers of modules
> (platform, news) this is a very lengthy
> process of splitting the bundles into
> dependency phases, then for each phase,
> releasing a new version of each bundle,
> updating the next phase's bundles with the
> newly released versions, and then releasing
> next phase's bundles, etc, etc. This can be a
> multiple hour process with Jenkins, compounded
> by the fact that you can only release one
> sub-project at a time in a Git repository to
> avoid push conflicts causing the build to
> fail. This process occurs much more frequently
> than I would have originally assumed. Right
> now I have a bash script that attempts to
> automate this for news with a combination of
> the maven release and version plugins, but a
> better generic solution would be very welcome.
>
> *Proposal: Modify Jenkins maven release plugin
> with the follo

Re: maven-release-plugin : How to better manage cascading releases

[Andrei Pozolotin]

*Jeff, Keith, Jeremy:*

so it seems we have few different use cases in mind between us.

it would probably help if we create 2-3 mock repositories on github
to emulate our most interesting use cases.

what do you think?

Andrei.


On Tuesday, February 26, 2013 12:06:16 AM UTC-6, Andrei Pozolotin wrote:
>
>Hello, there!
>
> I am curious : "How to better manage cascading releases"
> for the following use case and what you think about possible solution:
>
> #
> Releasing core bundles and dependent bundles 
>
> Changing the API of a core bundle for an application requires a rebuild of 
> everything down the line in order to use the new feature. For projects with 
> large numbers of modules (platform, news) this is a very lengthy process of 
> splitting the bundles into dependency phases, then for each phase, 
> releasing a new version of each bundle, updating the next phase's bundles 
> with the newly released versions, and then releasing next phase's bundles, 
> etc, etc. This can be a multiple hour process with Jenkins, compounded by 
> the fact that you can only release one sub-project at a time in a Git 
> repository to avoid push conflicts causing the build to fail. This process 
> occurs much more frequently than I would have originally assumed. Right now 
> I have a bash script that attempts to automate this for news with a 
> combination of the maven release and version plugins, but a better generic 
> solution would be very welcome.
>
> *Proposal: Modify Jenkins maven release plugin with the following 
> behavior:*
>
>1. 
>
>Add a "Cascade release dependent projects" checkbox on release page
> 2. 
>
>After the release completes, look for jobs that are explicitly 
>dependent on the pre-release snapshot version
> 3. 
>
>Update these dependent modules with the newly release version, and 
>trigger a Maven release on them as well
> 4. 
>
>Failing releases should be skipped, and then trigger a build failure 
>at the very end, with clearly noted messages as to which sub-tree failed 
> so 
>the user can check the logs and manually cascade release the subtree
> 
> Step c) would need some cycle detection to support scenarios where B and C 
> depend on A, but C also depends on B - both A and B would have to be 
> released before C could be released.
> #
>
> Thank you, 
>
> Andrei
>
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: maven-release-plugin : How to better manage cascading releases

[Andrei Pozolotin]

Jeff, Keith: would you be interested in collaborating on a jenkins
plugin for this? Andrei.

 Original Message 
Subject: Re: maven-release-plugin : How to better manage cascading releases
From: Keith Collison 
To: jenkinsci-users@googlegroups.com
Date: Tue 26 Feb 2013 09:40:59 PM CST
> We've put in place the first half of this by adding these goals to our
> maven builds:
>
> versions:use-releases scm:checkin
>
> The former will update a pom to use released versions of snapshot
> dependencies.  The latter commits any resulting changes to the
> pom.xml.  We also use the "includesList" parameter to limit the
> release check to our own libraries.  See this page
> <http://mojo.codehaus.org/versions-maven-plugin/use-releases-mojo.html> for
> info regarding this goal and plugin.
>
> Some caveats to this approach:
>
> 1.  If the pom.xml uses a property to define the dependency version
> (i.e. "${defined.elsewhere}"), the versions plugin
> will not update the version.
> 2.  The versions plugin only scans the module's  list. 
> If you have a parent-pom declaration whose version is set to a
> SNAPSHOT, it will not update it.
>
> I'd have reservations, I think, with the exact workflow you've
> described, as it might lead to unintended releases.  However, if you
> started from the most-dependent module (i.e. the webapp or application
> you want to release), and then calculated what upstream dependencies
> needed to be released, that would be ideal.  Just because I've
> released some base library upon which 20 apps depend does not mean I
> want to cut a release of those 20 apps.
>
>
>
>
>
>
> On Tuesday, February 26, 2013 1:06:16 AM UTC-5, Andrei Pozolotin wrote:
>
>   Hello, there!
>
> I am curious : "How to better manage cascading releases"
> for the following use case and what you think about possible
> solution:
>
> #
>
>
> Releasing core bundles and dependent bundles
>
> Changing the API of a core bundle for an application requires
> a rebuild of everything down the line in order to use the new
> feature. For projects with large numbers of modules (platform,
> news) this is a very lengthy process of splitting the bundles
> into dependency phases, then for each phase, releasing a new
> version of each bundle, updating the next phase's bundles with
> the newly released versions, and then releasing next phase's
> bundles, etc, etc. This can be a multiple hour process with
> Jenkins, compounded by the fact that you can only release one
> sub-project at a time in a Git repository to avoid push
> conflicts causing the build to fail. This process occurs much
> more frequently than I would have originally assumed. Right
> now I have a bash script that attempts to automate this for
> news with a combination of the maven release and version
> plugins, but a better generic solution would be very welcome.
>
> *Proposal: Modify Jenkins maven release plugin with the
> following behavior:*
>
> 1.
>
> Add a "Cascade release dependent projects" checkbox on
> release page
>
> 2.
>
> After the release completes, look for jobs that are
> explicitly dependent on the pre-release snapshot version
>
> 3.
>
> Update these dependent modules with the newly release
> version, and trigger a Maven release on them as well
>
> 4.
>
> Failing releases should be skipped, and then trigger a
> build failure at the very end, with clearly noted messages
> as to which sub-tree failed so the user can check the logs
> and manually cascade release the subtree
>
> Step c) would need some cycle detection to support scenarios
> where B and C depend on A, but C also depends on B - both A
> and B would have to be released before C could be released.
>
> #
>
> Thank you,
>
> Andrei
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: maven-release-plugin : How to better manage cascading releases

[Andrei Pozolotin]

Keith: very good points, thank you very much for sharing. Andrei.

 Original Message 
Subject: Re: maven-release-plugin : How to better manage cascading releases
From: Keith Collison 
To: jenkinsci-users@googlegroups.com
Date: Tue 26 Feb 2013 09:40:59 PM CST
> We've put in place the first half of this by adding these goals to our
> maven builds:
>
> versions:use-releases scm:checkin
>
> The former will update a pom to use released versions of snapshot
> dependencies.  The latter commits any resulting changes to the
> pom.xml.  We also use the "includesList" parameter to limit the
> release check to our own libraries.  See this page
> <http://mojo.codehaus.org/versions-maven-plugin/use-releases-mojo.html> for
> info regarding this goal and plugin.
>
> Some caveats to this approach:
>
> 1.  If the pom.xml uses a property to define the dependency version
> (i.e. "${defined.elsewhere}"), the versions plugin
> will not update the version.
> 2.  The versions plugin only scans the module's  list. 
> If you have a parent-pom declaration whose version is set to a
> SNAPSHOT, it will not update it.
>
> I'd have reservations, I think, with the exact workflow you've
> described, as it might lead to unintended releases.  However, if you
> started from the most-dependent module (i.e. the webapp or application
> you want to release), and then calculated what upstream dependencies
> needed to be released, that would be ideal.  Just because I've
> released some base library upon which 20 apps depend does not mean I
> want to cut a release of those 20 apps.
>
>
>
>
>
>
> On Tuesday, February 26, 2013 1:06:16 AM UTC-5, Andrei Pozolotin wrote:
>
>   Hello, there!
>
> I am curious : "How to better manage cascading releases"
> for the following use case and what you think about possible
> solution:
>
> #
>
>
> Releasing core bundles and dependent bundles
>
> Changing the API of a core bundle for an application requires
> a rebuild of everything down the line in order to use the new
> feature. For projects with large numbers of modules (platform,
> news) this is a very lengthy process of splitting the bundles
> into dependency phases, then for each phase, releasing a new
> version of each bundle, updating the next phase's bundles with
> the newly released versions, and then releasing next phase's
> bundles, etc, etc. This can be a multiple hour process with
> Jenkins, compounded by the fact that you can only release one
> sub-project at a time in a Git repository to avoid push
> conflicts causing the build to fail. This process occurs much
> more frequently than I would have originally assumed. Right
> now I have a bash script that attempts to automate this for
> news with a combination of the maven release and version
> plugins, but a better generic solution would be very welcome.
>
> *Proposal: Modify Jenkins maven release plugin with the
> following behavior:*
>
> 1.
>
> Add a "Cascade release dependent projects" checkbox on
> release page
>
> 2.
>
> After the release completes, look for jobs that are
> explicitly dependent on the pre-release snapshot version
>
> 3.
>
> Update these dependent modules with the newly release
> version, and trigger a Maven release on them as well
>
> 4.
>
> Failing releases should be skipped, and then trigger a
> build failure at the very end, with clearly noted messages
> as to which sub-tree failed so the user can check the logs
> and manually cascade release the subtree
>
> Step c) would need some cycle detection to support scenarios
> where B and C depend on A, but C also depends on B - both A
> and B would have to be released before C could be released.
>
> #
>
> Thank you,
>
> Andrei
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: maven-release-plugin : How to better manage cascading releases

[Andrei Pozolotin]

Jeff: thanks for the feedback. Andrei.

 Original Message 
Subject: Re: maven-release-plugin : How to better manage cascading releases
From: Jeff 
To: jenkinsci-users@googlegroups.com
Date: Tue 26 Feb 2013 12:14:07 AM CST
> I've thought about this too, there could be a logistics issues with
> how/where to find the dependent projects unless you have a
> multi-module POM (parent + children) or some other way to either tell
> it where to find the dependencies or impose a rigid project/folder
> structure.
>
> I wonder if this type of behavior (cascading releases) should be part
> of a build tool like Jenkins or an IDE plugin since these types of
> tools likely already have the knowledge of needed dependencies.
>
>
>
> On Mon, Feb 25, 2013 at 11:06 PM, Andrei Pozolotin
> mailto:andrei.pozolo...@gmail.com>> wrote:
>
>   Hello, there!
>
> I am curious : "How to better manage cascading releases"
> for the following use case and what you think about possible
> solution:
>
> #
>
>
> Releasing core bundles and dependent bundles
>
> Changing the API of a core bundle for an application requires
> a rebuild of everything down the line in order to use the new
> feature. For projects with large numbers of modules (platform,
> news) this is a very lengthy process of splitting the bundles
> into dependency phases, then for each phase, releasing a new
> version of each bundle, updating the next phase's bundles with
> the newly released versions, and then releasing next phase's
> bundles, etc, etc. This can be a multiple hour process with
> Jenkins, compounded by the fact that you can only release one
> sub-project at a time in a Git repository to avoid push
> conflicts causing the build to fail. This process occurs much
> more frequently than I would have originally assumed. Right
> now I have a bash script that attempts to automate this for
> news with a combination of the maven release and version
> plugins, but a better generic solution would be very welcome.
>
> *Proposal: Modify Jenkins maven release plugin with the
> following behavior:*
>
> 1.
>
> Add a "Cascade release dependent projects" checkbox on
> release page
>
> 2.
>
> After the release completes, look for jobs that are
> explicitly dependent on the pre-release snapshot version
>
> 3.
>
> Update these dependent modules with the newly release
> version, and trigger a Maven release on them as well
>
> 4.
>
> Failing releases should be skipped, and then trigger a
> build failure at the very end, with clearly noted messages
> as to which sub-tree failed so the user can check the logs
> and manually cascade release the subtree
>
> Step c) would need some cycle detection to support scenarios
> where B and C depend on A, but C also depends on B - both A
> and B would have to be released before C could be released.
>
> #
>
> Thank you,
>
> Andrei
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to jenkinsci-users+unsubscr...@googlegroups.com
> <mailto:jenkinsci-users%2bunsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
>
>
>
>
> -- 
> Jeff Vincent
> predato...@gmail.com <mailto:predato...@gmail.com>
> See my LinkedIn profile at:
> http://www.linkedin.com/in/rjeffreyvincent
> I ♥ DropBox <http://db.tt/9O6LfBX> !! 
> -- 
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/4OZsB9LV6nE/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

maven-release-plugin : How to better manage cascading releases

[Andrei Pozolotin]

 

  Hello, there!

I am curious : "How to better manage cascading releases"
for the following use case and what you think about possible solution:

#
Releasing core bundles and dependent bundles 

Changing the API of a core bundle for an application requires a rebuild of 
everything down the line in order to use the new feature. For projects with 
large numbers of modules (platform, news) this is a very lengthy process of 
splitting the bundles into dependency phases, then for each phase, 
releasing a new version of each bundle, updating the next phase's bundles 
with the newly released versions, and then releasing next phase's bundles, 
etc, etc. This can be a multiple hour process with Jenkins, compounded by 
the fact that you can only release one sub-project at a time in a Git 
repository to avoid push conflicts causing the build to fail. This process 
occurs much more frequently than I would have originally assumed. Right now 
I have a bash script that attempts to automate this for news with a 
combination of the maven release and version plugins, but a better generic 
solution would be very welcome.

*Proposal: Modify Jenkins maven release plugin with the following behavior:*

   1. 
   
   Add a "Cascade release dependent projects" checkbox on release page
2. 
   
   After the release completes, look for jobs that are explicitly dependent 
   on the pre-release snapshot version
3. 
   
   Update these dependent modules with the newly release version, and 
   trigger a Maven release on them as well
4. 
   
   Failing releases should be skipped, and then trigger a build failure at 
   the very end, with clearly noted messages as to which sub-tree failed so 
   the user can check the logs and manually cascade release the subtree

Step c) would need some cycle detection to support scenarios where B and C 
depend on A, but C also depends on B - both A and B would have to be 
released before C could be released.
#

Thank you, 

Andrei

 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Dependent Maven Jobs ignore version-number

[Andrei Pozolotin]

re: Dependent Maven Jobs ignore version-number
https://issues.jenkins-ci.org/browse/JENKINS-15237

only about 30 people voted for 
JENKINS-15237
; 
I am curious what is the extent of the problem?

Re: jenkins bug: rootPOM disappears

[Andrei Pozolotin]

please add your comments here
https://issues.jenkins-ci.org/browse/JENKINS-14123

On Wednesday, June 6, 2012 11:07:24 AM UTC-5, Andrei Pozolotin wrote:
>
> jenkns version 1.467
>
> problem:
>
> project uses rootPOM path spec such as
> parent/child/pom.xml
>
> if you edit job config after change rootPOM entry looks fine
>
> after jenkins restart, if you edit job config now,
> rootPOM entry looks empty, despite appropriate entry
> is present OK in job/config.xml and job builds fine;
>
> if you now merely edit and save job config,
> the rootPOM entry is lost in job/config.xml
> and job does not build any more
>
>

Re: jenkins bug: rootPOM disappears

[Andrei Pozolotin]

Vincent:

I can not see this in the changelog
http://jenkins-ci.org/changelog

which issue was that?

Andrei.


On Saturday, June 9, 2012 4:47:36 AM UTC-5, Vincent Latombe wrote:
>
> Hello,
>
> I think this has already been fixed toward 1.469, since it was causing 
> regressions with sonar jobs as well.
>
> Vincent
>
>
> 2012/6/8 Andrei Pozolotin 
>
>> can you please file this bug on jenkins bug tracker?
>> (I can not access it)
>> thank you.
>>
>>
>> On Wednesday, June 6, 2012 11:07:24 AM UTC-5, Andrei Pozolotin wrote:
>>>
>>> jenkns version 1.467
>>>
>>> problem:
>>>
>>> project uses rootPOM path spec such as
>>> parent/child/pom.xml
>>>
>>> if you edit job config after change rootPOM entry looks fine
>>>
>>> after jenkins restart, if you edit job config now,
>>> rootPOM entry looks empty, despite appropriate entry
>>> is present OK in job/config.xml and job builds fine;
>>>
>>> if you now merely edit and save job config,
>>> the rootPOM entry is lost in job/config.xml
>>> and job does not build any more
>>>
>>>
>

Re: jenkins bug: rootPOM disappears

[Andrei Pozolotin]

can you please file this bug on jenkins bug tracker?
(I can not access it)
thank you.

On Wednesday, June 6, 2012 11:07:24 AM UTC-5, Andrei Pozolotin wrote:
>
> jenkns version 1.467
>
> problem:
>
> project uses rootPOM path spec such as
> parent/child/pom.xml
>
> if you edit job config after change rootPOM entry looks fine
>
> after jenkins restart, if you edit job config now,
> rootPOM entry looks empty, despite appropriate entry
> is present OK in job/config.xml and job builds fine;
>
> if you now merely edit and save job config,
> the rootPOM entry is lost in job/config.xml
> and job does not build any more
>
>

jenkins bug: rootPOM disappears

[Andrei Pozolotin]

jenkns version 1.467

problem:

project uses rootPOM path spec such as
parent/child/pom.xml

if you edit job config after change rootPOM entry looks fine

after jenkins restart, if you edit job config now,
rootPOM entry looks empty, despite appropriate entry
is present OK in job/config.xml and job builds fine;

if you now merely edit and save job config,
the rootPOM entry is lost in job/config.xml
and job does not build any more

can not file bugs

[Andrei Pozolotin]

people running jenkins-ci servers:

I can not file jenkins bugs:
https://jenkins-ci.org/account

I can not remember my login, and password reset email never comes back;

can you please reset for me the account andrei_pozolotin

?