[JIRA] (JENKINS-6797) Add @DataBoundConstructor

2012-04-29 Thread daca...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162195#comment-162195
 ] 

Dave Carey commented on JENKINS-6797:
-

Am I right in concluding that ant Groovy Script or Command is off-limits as a 
pre-build step until this issue is resolved?

Cheers
Dave



 Add @DataBoundConstructor
 -

 Key: JENKINS-6797
 URL: https://issues.jenkins-ci.org/browse/JENKINS-6797
 Project: Jenkins
  Issue Type: Improvement
  Components: groovy
 Environment: All
Reporter: domi
Assignee: vjuranek

 DescriptorImpl.newInstance() is deprecated since a while and 
 @DataBoundConstructor should be used instead.
 Builders not having a @DataBoundConstructor can't be used within Extensions 
 (e.g. BuildWrappers) a using @DataBoundConstructor itself.
 Please add a @DataBoundConstructor to 
 - hudson.plugins.groovy.Groovy 
 and
 - hudson.plugins.groovy.ScriptSource
 Caused by: java.lang.IllegalArgumentException: Failed to instantiate class 
 hudson.plugins.groovy.Groovy from 
 {groovyName:(Default),kind:hudson.plugins.groovy.Groovy$DescriptorImpl,parameters:,properties:,scriptParameters:,scriptSource:{scriptFile:dummy.groovy,value:0},stapler-class:hudson.plugins.groovy.Groovy}
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:352)
   at 
 org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:552)
   at 
 org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:587)
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:344)
   ... 40 more
 Caused by: org.kohsuke.stapler.NoStaplerConstructorException: There's no 
 @DataBoundConstructor on any constructor of class hudson.plugins.groovy.Groovy
   at 
 org.kohsuke.stapler.RequestImpl.loadConstructorParamNames(RequestImpl.java:461)
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:331)
 Caused by: java.lang.IllegalArgumentException: Failed to convert the 
 scriptSource parameter of the constructor public 
 hudson.plugins.groovy.SystemGroovy(hudson.plugins.groovy.ScriptSource,java.lang.String,java.lang.String)
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:346)
   ... 43 more
 Caused by: java.lang.IllegalArgumentException: Failed to instantiate 
 interface hudson.plugins.groovy.ScriptSource from 
 {command:println(\hello\),value:1}
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:352)
   at 
 org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:552)
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:344)
   ... 43 more
 Caused by: org.kohsuke.stapler.NoStaplerConstructorException: There's no 
 @DataBoundConstructor on any constructor of interface 
 hudson.plugins.groovy.ScriptSource
   at 
 org.kohsuke.stapler.RequestImpl.loadConstructorParamNames(RequestImpl.java:461)
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:331)
 The same already had to be done for 'hudson.tasks.Shell' in the core - see 
 http://hudson.361315.n4.nabble.com/DataBoundConstructor-td2244199.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[JIRA] (JENKINS-6797) Add @DataBoundConstructor

2012-04-29 Thread daca...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-6797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162195#comment-162195
 ] 

Dave Carey edited comment on JENKINS-6797 at 4/29/12 8:05 AM:
--

Am I right in concluding that any Groovy Script or Command is off-limits as a 
pre-build step until this issue is resolved?

Cheers
Dave



  was (Author: davidcarey36):
Am I right in concluding that ant Groovy Script or Command is off-limits as 
a pre-build step until this issue is resolved?

Cheers
Dave


  
 Add @DataBoundConstructor
 -

 Key: JENKINS-6797
 URL: https://issues.jenkins-ci.org/browse/JENKINS-6797
 Project: Jenkins
  Issue Type: Improvement
  Components: groovy
 Environment: All
Reporter: domi
Assignee: vjuranek

 DescriptorImpl.newInstance() is deprecated since a while and 
 @DataBoundConstructor should be used instead.
 Builders not having a @DataBoundConstructor can't be used within Extensions 
 (e.g. BuildWrappers) a using @DataBoundConstructor itself.
 Please add a @DataBoundConstructor to 
 - hudson.plugins.groovy.Groovy 
 and
 - hudson.plugins.groovy.ScriptSource
 Caused by: java.lang.IllegalArgumentException: Failed to instantiate class 
 hudson.plugins.groovy.Groovy from 
 {groovyName:(Default),kind:hudson.plugins.groovy.Groovy$DescriptorImpl,parameters:,properties:,scriptParameters:,scriptSource:{scriptFile:dummy.groovy,value:0},stapler-class:hudson.plugins.groovy.Groovy}
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:352)
   at 
 org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:552)
   at 
 org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:587)
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:344)
   ... 40 more
 Caused by: org.kohsuke.stapler.NoStaplerConstructorException: There's no 
 @DataBoundConstructor on any constructor of class hudson.plugins.groovy.Groovy
   at 
 org.kohsuke.stapler.RequestImpl.loadConstructorParamNames(RequestImpl.java:461)
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:331)
 Caused by: java.lang.IllegalArgumentException: Failed to convert the 
 scriptSource parameter of the constructor public 
 hudson.plugins.groovy.SystemGroovy(hudson.plugins.groovy.ScriptSource,java.lang.String,java.lang.String)
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:346)
   ... 43 more
 Caused by: java.lang.IllegalArgumentException: Failed to instantiate 
 interface hudson.plugins.groovy.ScriptSource from 
 {command:println(\hello\),value:1}
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:352)
   at 
 org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:552)
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:344)
   ... 43 more
 Caused by: org.kohsuke.stapler.NoStaplerConstructorException: There's no 
 @DataBoundConstructor on any constructor of interface 
 hudson.plugins.groovy.ScriptSource
   at 
 org.kohsuke.stapler.RequestImpl.loadConstructorParamNames(RequestImpl.java:461)
   at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:331)
 The same already had to be done for 'hudson.tasks.Shell' in the core - see 
 http://hudson.361315.n4.nabble.com/DataBoundConstructor-td2244199.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[JIRA] (JENKINS-11553) WORKSPACE env var on Slave VM running windows has unix path separators instead of windows

2012-04-29 Thread gb...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-11553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162196#comment-162196
 ] 

gbois commented on JENKINS-11553:
-

Could you give your plugin list?
Maybe you are using the EnvInject Jenkins plugin and there is an issue on it.

 WORKSPACE env var on Slave VM running windows has unix path separators 
 instead of windows
 -

 Key: JENKINS-11553
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11553
 Project: Jenkins
  Issue Type: Bug
  Components: vsphere-cloud
 Environment: Jenkins: Linux 64 bit
 Slave: windows 7 64 bit
Reporter: Todd Livesey
Assignee: jswager

 When Jenkins running on Linux issues a job to a vm slave running windows 7, 
 the WORKSPACE environment variable received by the slave running a batch file 
 has Unix style path separators (/) instead of windows style path separators 
 (\). As a result, batch file commands such as 'DEL %WORKSPACE%\*' results in 
 a failure such as 'users is not a valid option' (because WORKSPACE is set to 
 C:/users/build/workspace).
 Other combinations of Jenkins/slave OSs not attempted.
 Workaround is to simply replace '/' with '\' in WORKSPACE and job runs 
 smoothly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[JIRA] (JENKINS-13227) CVS plugin 2.1 does not detect changes

2012-04-29 Thread michael.m.cla...@gmail.com (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Clarke reassigned JENKINS-13227:


Assignee: Michael Clarke  (was: Kohsuke Kawaguchi)

 CVS plugin 2.1 does not detect changes
 --

 Key: JENKINS-13227
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13227
 Project: Jenkins
  Issue Type: Bug
  Components: cvs
Reporter: Guillaume Bilodeau
Assignee: Michael Clarke
Priority: Critical
  Labels: cvs

 As presented in the user group: 
 https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Dvv0I3FBNW4
 We've been running Jenkins 1.451 and 1.454 on Windows XP against a CVS 
 repository for a few weeks now, without any problems. The CVS plugin (v1.6) 
 was using the local cvsnt install.
 We've since upgraded the CVS plugin to version 2.1 (by manually pinning the 
 plugin) and since then, CVS changes are not detected. The CVS polling log is 
 triggered properly, tons of cvs rlog instructions are sent, but at the end 
 No changes is displayed.
 Using CVS plugin 1.6 the cvs polling command looked like this (executed at 
 5:26:21 PM EDT):
 cvs -q -z3 -n update -PdC -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 
 Thursday, March 22, 2012 9:26:21 PM UTC
 Using CVS plugin 2.1, the last cvs checkout command looked like this 
 (executed at 11:56:16 AM EDT):
 cvs checkout -P -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 23 Mar 2012 
 11:56:16 EDT -d portailInt portailInt
 We're in Montreal, so Eastern Time Zone with Daylight Saving Time in effect.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[JIRA] (JENKINS-13140) Disconnected slaves come back online within a few minutes

2012-04-29 Thread norman.baum...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162197#comment-162197
 ] 

Norman Baumann commented on JENKINS-13140:
--

Hey Marc,

I don't know what a Swarm client is. Can you clarify this for me?

I have created the slave as a dump slave. Setting it's status to offline has 
the same effect as disconnecting.

 Disconnected slaves come back online within a few minutes
 -

 Key: JENKINS-13140
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13140
 Project: Jenkins
  Issue Type: Bug
  Components: slave-setup
Affects Versions: current
 Environment: Linux Jenkins Master and build slave
Reporter: Norman Baumann
Assignee: Kohsuke Kawaguchi

 I have a Jenkins installation with 20 build slaves. A couple of minutes after 
 I click on Disconnect slave, the slave is back online.
 The log contains:
 Mar 19, 2012 5:22:19 PM hudson.slaves.SlaveComputer tryReconnect
 INFO: Attempting to reconnect musxdodo77
 Somehow Jenkins is ignoring the offline tag when set manually.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[JIRA] (JENKINS-12037) CLI - I/O error in channel Chunked connection/Unexpected termination of the channel - still occurring in Jenkins 1.449

2012-04-29 Thread mosh...@amdocs.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-12037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162198#comment-162198
 ] 

Moshe Sucaz commented on JENKINS-12037:
---

Hi,
We have just downloaded Jenkins 1.461 (because we had this problem with 1.443), 
and I still see such failures in catalina logs. we are using tomcat 6.0.29. 
will upgrade to Tomcat 7.0.22 help?

 CLI - I/O error in channel Chunked connection/Unexpected termination of the 
 channel - still occurring in Jenkins 1.449
 --

 Key: JENKINS-12037
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12037
 Project: Jenkins
  Issue Type: Bug
  Components: cli
 Environment: * Running on SLES9 Linux server with 4 CPUs and plenty 
 of diskspace.
 * Tomcat 7.0.22
 * JDK 1.6.0_14
 * Only ONE Master configuration - no slaves are configured
 * 3 Executors - (one less than the max number of CPUs) 
Reporter: mark streit
Priority: Critical
 Attachments: jenkins-timeout, Tomcat7_Jenkins1449_logs.zip


 We reported an issue some time back that was also listed as fixed in Jenkins 
 1.441:
 Log:
 [FIXED JENKINS-11130] SEVERE: I/O error in channel Chunked connection when 
 using jenkins-cli.jar
 Perhaps another bug should NOT be submitted so I have added the following 
 comments below the line to the original defect 11130 comments section in case 
 it can be reviewed/re-opened.
 We did NOT try to make any adjustments to the Tomcat configuration:
 Tomcat Connector connectionUploadTimeout
 but we are also now seeing the same problem with Winstone when at this same 
 1.441 level.  We did revert to the 1.438 version of the CLI (leaving the WAR 
 at 1.441 running in Winstone) and that is serving asthe current workaround.
 
 We have downloaded and installed the LATEST 1.441 release that lists the fix 
 for this problem. Currently we were running 1.438 on Winstone only (since 
 with Tomcat 6 or 7, we had experienced the error HOWEVER yet under Winstone, 
 it worked OK so that was our workaround - while running 1.438).
 Now with Jenkins 1.441 - we are getting the ERROR again and NOW WITH BOTH 
 Winstone and the Tomcat configurations). We have left the Jenkins 1.441 WAR 
 file in place running on Winstone, and reverted the CLI jar file back to the 
 1.438 version for now and that appears to work again with Winstone.
 Checked Manifest of CLI jar downloaded with the 1.441 WAR installation:
 Manifest-Version: 1.0
 Archiver-Version: Plexus Archiver
 Created-By: Apache Maven
 Built-By: kohsuke
 Build-Jdk: 1.6.0_26
 Main-Class: hudson.cli.CLI
 Jenkins-CLI-Version: 1.441
 Under Tomcat 7, we get this stacktrace:
 Started by command line
 [workspace] $ /bin/bash -xe 
 /opt/apache-tomcat-7.0.22_jenkins/temp/hudson3281734817830.sh
 + /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar 
 -s http://11.22.33.44:8082/jenkins/ build XYZ_Project-SharedLibs -s -p 
 SVN_PATH=trunk
 Dec 5, 2011 12:59:11 PM hudson.remoting.Channel$ReaderThread run
 SEVERE: I/O error in channel Chunked connection to 
 http://11.22.33.44:8082/jenkins/cli
 java.io.IOException: Unexpected termination of the channel
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115)
 Caused by: java.io.EOFException
 at 
 java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109)
 Exception in thread main hudson.remoting.RequestAbortedException: 
 hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
 termination of the channel
 at hudson.remoting.Request.call(Request.java:149)
 at hudson.remoting.Channel.call(Channel.java:681)
 at 
 hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158)
 at $Proxy2.main(Unknown Source)
 at hudson.cli.CLI.execute(CLI.java:200)
 at hudson.cli.CLI._main(CLI.java:330)
 at hudson.cli.CLI.main(CLI.java:245)
 Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: 
 Unexpected termination of the channel
 at hudson.remoting.Request.abort(Request.java:273)
 at hudson.remoting.Channel.terminate(Channel.java:732)
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:1139)
 Caused by: java.io.IOException: Unexpected termination of the channel
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115)
 Caused by: java.io.EOFException
 at 
 java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554)
 at 

[JIRA] (JENKINS-12037) CLI - I/O error in channel Chunked connection/Unexpected termination of the channel - still occurring in Jenkins 1.449

2012-04-29 Thread mcs...@gmail.com (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-12037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162199#comment-162199
 ] 

mark streit commented on JENKINS-12037:
---

A couple of things with this:

1) you need to make sure you download and install the latest jenkins-cli.jar 
that comes with 1.460 or higher version of the WAR download...and have it in 
your classpath wherever you are utilizing the CLI jar.  
2) It's the CLI jar code that was fixed as part of this.  Simply updating the 
WAR file on your Tomcat instance is only part of the upgrade.
3) I checked our catalina.out logs on our Tomcat 7.0.22 installation and we 
don't see these anymore since the fix was delivered in 1.460 which is what we 
now run.  We made sure wherever we use CLI commands that the 1.460 version of 
the jenkins-cli.jar is on the classpath. 

Hope this helps.

 CLI - I/O error in channel Chunked connection/Unexpected termination of the 
 channel - still occurring in Jenkins 1.449
 --

 Key: JENKINS-12037
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12037
 Project: Jenkins
  Issue Type: Bug
  Components: cli
 Environment: * Running on SLES9 Linux server with 4 CPUs and plenty 
 of diskspace.
 * Tomcat 7.0.22
 * JDK 1.6.0_14
 * Only ONE Master configuration - no slaves are configured
 * 3 Executors - (one less than the max number of CPUs) 
Reporter: mark streit
Priority: Critical
 Attachments: jenkins-timeout, Tomcat7_Jenkins1449_logs.zip


 We reported an issue some time back that was also listed as fixed in Jenkins 
 1.441:
 Log:
 [FIXED JENKINS-11130] SEVERE: I/O error in channel Chunked connection when 
 using jenkins-cli.jar
 Perhaps another bug should NOT be submitted so I have added the following 
 comments below the line to the original defect 11130 comments section in case 
 it can be reviewed/re-opened.
 We did NOT try to make any adjustments to the Tomcat configuration:
 Tomcat Connector connectionUploadTimeout
 but we are also now seeing the same problem with Winstone when at this same 
 1.441 level.  We did revert to the 1.438 version of the CLI (leaving the WAR 
 at 1.441 running in Winstone) and that is serving asthe current workaround.
 
 We have downloaded and installed the LATEST 1.441 release that lists the fix 
 for this problem. Currently we were running 1.438 on Winstone only (since 
 with Tomcat 6 or 7, we had experienced the error HOWEVER yet under Winstone, 
 it worked OK so that was our workaround - while running 1.438).
 Now with Jenkins 1.441 - we are getting the ERROR again and NOW WITH BOTH 
 Winstone and the Tomcat configurations). We have left the Jenkins 1.441 WAR 
 file in place running on Winstone, and reverted the CLI jar file back to the 
 1.438 version for now and that appears to work again with Winstone.
 Checked Manifest of CLI jar downloaded with the 1.441 WAR installation:
 Manifest-Version: 1.0
 Archiver-Version: Plexus Archiver
 Created-By: Apache Maven
 Built-By: kohsuke
 Build-Jdk: 1.6.0_26
 Main-Class: hudson.cli.CLI
 Jenkins-CLI-Version: 1.441
 Under Tomcat 7, we get this stacktrace:
 Started by command line
 [workspace] $ /bin/bash -xe 
 /opt/apache-tomcat-7.0.22_jenkins/temp/hudson3281734817830.sh
 + /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar 
 -s http://11.22.33.44:8082/jenkins/ build XYZ_Project-SharedLibs -s -p 
 SVN_PATH=trunk
 Dec 5, 2011 12:59:11 PM hudson.remoting.Channel$ReaderThread run
 SEVERE: I/O error in channel Chunked connection to 
 http://11.22.33.44:8082/jenkins/cli
 java.io.IOException: Unexpected termination of the channel
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115)
 Caused by: java.io.EOFException
 at 
 java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
 at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109)
 Exception in thread main hudson.remoting.RequestAbortedException: 
 hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
 termination of the channel
 at hudson.remoting.Request.call(Request.java:149)
 at hudson.remoting.Channel.call(Channel.java:681)
 at 
 hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158)
 at $Proxy2.main(Unknown Source)
 at hudson.cli.CLI.execute(CLI.java:200)
 at hudson.cli.CLI._main(CLI.java:330)
 at hudson.cli.CLI.main(CLI.java:245)
 Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: 
 Unexpected termination of the 

[JIRA] (JENKINS-11964) [Regression] Cannot build a single module in a Maven multi-module job with Maven 3

2012-04-29 Thread ol...@apache.org (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-11964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

olamy reassigned JENKINS-11964:
---

Assignee: olamy

 [Regression] Cannot build a single module in a Maven multi-module job with 
 Maven 3
 --

 Key: JENKINS-11964
 URL: https://issues.jenkins-ci.org/browse/JENKINS-11964
 Project: Jenkins
  Issue Type: Bug
  Components: maven
Reporter: henryju
Assignee: olamy

 We have upgraded from Jenkins 1.399 to Jenkins 1.441. Our Maven jobs are now 
 run by Maven 3.0.3 instead of Maven 2.2.1.
 When a job is a Maven multi-module project, it is possible to run a single 
 submodule (on the job page, click on Modules, then start the build for a 
 given submodule). It was working fine with our old instance but now the build 
 fails with status ABORTED.
 See thread: 
 http://jenkins.361315.n4.nabble.com/Build-Maven-submodule-gt-ABORTED-td4128116.html
 Is it possible to reintroduce this feature?
 Thanks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[JIRA] (JENKINS-6681) Maven-generated site link gives 404

2012-04-29 Thread ol...@apache.org (JIRA)

 [ 
https://issues.jenkins-ci.org/browse/JENKINS-6681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

olamy reassigned JENKINS-6681:
--

Assignee: olamy

 Maven-generated site link gives 404
 ---

 Key: JENKINS-6681
 URL: https://issues.jenkins-ci.org/browse/JENKINS-6681
 Project: Jenkins
  Issue Type: Bug
  Components: maven2
Affects Versions: current
Reporter: adico
Assignee: olamy

 After running goals clean install site in a Maven2 build, project home page
 shows a link called Maven-generated site. This links gives a 404 because it
 is missing project-info.html off the end of the URL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[JIRA] (JENKINS-12918) a job dedicated to copyartifacts from a build specified by a build paramter (ie a run parameter) fails when launched manuallyco

2012-04-29 Thread mindl...@java.net (JIRA)

[ 
https://issues.jenkins-ci.org/browse/JENKINS-12918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162200#comment-162200
 ] 

Alan Harder commented on JENKINS-12918:
---

I think there's some confusion on the purpose of the Run parameter.. it is for 
how to select a build, not about which project.. so this:

{{it defines a Run parameter (named IFW) to select a build from the job 
IFW}}

is not possible.  You simply define a build selector parameter named IFW and a 
default value.
When you add a Copy Artifact build step to the job you must specify the project 
to copy from (probably IFW in this case), and then for the build to select 
you can choose from build parameter and give IFW as the parameter name 
(using the name IFW for the build parameter is perhaps part of the confusion).

I just tried using a run parameter with Jenkins 1.461 and Copy Artifact 1.22, 
and didn't see any error.  If you still see a problem, perhaps try in a 
different environment or setup and see if you can narrow down what factors 
cause the error.


 a job dedicated to copyartifacts from a build specified by a build paramter 
 (ie a run  parameter)  fails when launched manuallyco
 -

 Key: JENKINS-12918
 URL: https://issues.jenkins-ci.org/browse/JENKINS-12918
 Project: Jenkins
  Issue Type: Bug
  Components: copyartifact
 Environment: Jenkins ver. 1.450
 copy artifacts plugin v1.21
Reporter: christopheM
Assignee: Alan Harder
 Attachments: config.xml


 The tested job is minimalist:
 - it defines a Run parameter (named IFW) to select a build from the job 
 IFW
 - it defines a copy artifacts from another project specified by a build 
 parameter, the parameter name beeing IFW, and selectif the followinfg 
 artifacts **/*zip
 When manually launching the job, selecting the (succesful) last build of the 
 IFW job, I got the following error:
 FATAL:  : only whitespace content allowed before start tag and not h 
 (position: START_DOCUMENT seen h... @1:1)
 com.thoughtworks.xstream.io.StreamException:  : only whitespace content 
 allowed before start tag and not h (position: START_DOCUMENT seen h... @1:1)
   at 
 com.thoughtworks.xstream.io.xml.XppReader.pullNextEvent(XppReader.java:78)
   at 
 com.thoughtworks.xstream.io.xml.AbstractPullReader.readRealEvent(AbstractPullReader.java:154)
   at 
 com.thoughtworks.xstream.io.xml.AbstractPullReader.readEvent(AbstractPullReader.java:147)
   at 
 com.thoughtworks.xstream.io.xml.AbstractPullReader.move(AbstractPullReader.java:126)
   at 
 com.thoughtworks.xstream.io.xml.AbstractPullReader.moveDown(AbstractPullReader.java:111)
   at com.thoughtworks.xstream.io.xml.XppReader.init(XppReader.java:48)
   at 
 com.thoughtworks.xstream.io.xml.XppDriver.createReader(XppDriver.java:44)
   at com.thoughtworks.xstream.XStream.fromXML(XStream.java:856)
   at com.thoughtworks.xstream.XStream.fromXML(XStream.java:848)
   at 
 hudson.plugins.copyartifact.BuildSelectorParameter.getSelectorFromXml(BuildSelectorParameter.java:81)
   at 
 hudson.plugins.copyartifact.ParameterizedBuildSelector.getBuild(ParameterizedBuildSelector.java:52)
   at 
 hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:164)
   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
   at 
 hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700)
   at hudson.model.Build$RunnerImpl.build(Build.java:178)
   at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
   at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470)
   at hudson.model.Run.run(Run.java:1409)
   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
   at hudson.model.ResourceController.execute(ResourceController.java:88)
   at hudson.model.Executor.run(Executor.java:238)
 Caused by: org.xmlpull.v1.XmlPullParserException: only whitespace content 
 allowed before start tag and not h (position: START_DOCUMENT seen h... @1:1) 
   at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1519)
   at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395)
   at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)
   at 
 com.thoughtworks.xstream.io.xml.XppReader.pullNextEvent(XppReader.java:63)
   ... 20 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira