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

[michael.m.cla...@gmail.com (JIRA)]

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

Michael Clarke commented on JENKINS-13227:
--

I was reviewing the CVS manual last night and it doesn't provide much insight. 
I can't find suitable free CVS hosting on the internet so I'm going to have to 
bite-the-bullet and try and setup a CVS server on my computer (my previous 
setup was lost when my primary computer died). Since I don't have access to 
your CVS server, could you confirm the setup (CVS Server version, 
authentication mechanism, how you connect etc) and also confirm that this issue 
only seems to happen on branches (polling seems to work on the head). 

Thanks

> 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
> Attachments: rlog.txt
>
>
> 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-13737) Javascript error when selecting "Editable Email Notification"

[amitanand...@gmail.com (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162880#comment-162880
 ] 

amit anand commented on JENKINS-13737:
--

I am facing same problem with Jenkins ver. 1.463 and Jenkins ver. 1.464 with 
Chrome browser19.0.1084.46 m

Work around is also not working

> Javascript error when selecting "Editable Email Notification"
> -
>
> Key: JENKINS-13737
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13737
> Project: Jenkins
>  Issue Type: Bug
>  Components: email-ext
>Affects Versions: current
> Environment: Windows, IE8, Jenkins 1.463, Jenkins Email Extension 
> Plugin 2.20
>Reporter: Noel Bernardez
>Assignee: Slide-O-Mix
>  Labels: email-ext, jenkins
>
> In Jenkins ver. 1.463, when selecting "Editable Email Notification" in the 
> "Add post-build action", getting the following Javascript error 
> Message: 'emailExtInit' is undefined
> Line: 480
> Char: 17
> Code: 0
> URI: http://myserver:8080/static/f11a6618/scripts/hudson-behavior.js

--
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-13808) Status code 404 jenkins in v1.462 after login

[huen.l...@iproperty.com (JIRA)]

Ray Chan created JENKINS-13808:
--

 Summary: Status code 404 jenkins in v1.462 after login
 Key: JENKINS-13808
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13808
 Project: Jenkins
  Issue Type: Bug
  Components: other
Reporter: Ray Chan


Is only showing:
Exception: 
Stacktrace:
(none)

--
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-13809) Template variables are permanently overwritten on first use

[j...@joncairns.com (JIRA)]

Jon Cairns created JENKINS-13809:


 Summary: Template variables are permanently overwritten on first 
use
 Key: JENKINS-13809
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13809
 Project: Jenkins
  Issue Type: Bug
  Components: jenkins-plugin-runtime
Affects Versions: current
 Environment: Should happen on all systems and versions.
Reporter: Jon Cairns
Assignee: Jon Cairns


Meme configurations that include template variables such as "${project}" will 
be overwritten with the actual name of the project that first uses that Meme, 
as the Meme object is not copied/cloned, and it is automatically saved. The fix 
is to create a copy of the object and use that for the Meme generation.

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

Re: [JIRA] (JENKINS-13808) Status code 404 jenkins in v1.462 after login

[Niranjan Bansal]

Once you login you may be directed to the default view or job that no
longer exist. Please check and preferably share the screenshot

Thanks
Niranjan

On Thu, May 17, 2012 at 1:32 PM, huen.l...@iproperty.com (JIRA) <
nore...@jenkins-ci.org> wrote:

> Ray Chan created JENKINS-13808:
> --
>
> Summary: Status code 404 jenkins in v1.462 after login
> Key: JENKINS-13808
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13808
> Project: Jenkins
>  Issue Type: Bug
>  Components: other
>Reporter: Ray Chan
>
>
> Is only showing:
> Exception:
> Stacktrace:
> (none)
>
> --
> 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
>
>
>


-- 
Regards
Niranjan Bansal

[JIRA] (JENKINS-13810) Maven modules marked to wrong build when running concurrent job

[jyrki...@gmail.com (JIRA)]

Jyrki Puttonen created JENKINS-13810:


 Summary: Maven modules marked to wrong build when running 
concurrent job
 Key: JENKINS-13810
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13810
 Project: Jenkins
  Issue Type: Bug
  Components: concurrent-build, maven
Reporter: Jyrki Puttonen
Assignee: Kohsuke Kawaguchi


I have a Maven project build with one module, named jenkins-test. This module 
contains one test, which fails everytime (assertTrue(false) :)). There is a 
problem when this project is executed with "Execute concurrent builds if 
necessary" turned on and when multiple jobs are started at same time. Multiple 
builds start and finish, but some of these jobs are completed succesfully and 
some are marked as failed. What I see in the build status page is something 
like this:

(Success) Build #180 (May 12, 2012 8:17:09 PM)
...
Module Builds
jenkins-test (didn't run)

(Success) Build #181 (May 12, 2012 8:17:12 PM)
...
Module Builds
(disabled) jenkins-test (didn't run)

(Unstable) Build #182 (May 12, 2012 8:17:19 PM)
...
Module Builds
jenkins-test (Unstable) #182 (Unstable) #183 (Unstable) #184

Logs show that the builds were executed properly (commit ids are right, and 
"[ERROR] There are test failures." is there). The next build then gets build 
number #187.

In my setup I'm using Gerrit and Gerrit Trigger to launch jobs, so when I push 
multiple commits into Gerrit in one push, Jenkins starts multiple jobs at same 
time. I don't know if you can duplicate this behavior without Gerrit, though.

Currently MavenModule and MavenModuleSet have their own build numbers, which 
are increment when a new module is built. These might get mixed up when 
multiple builds are executed concurrently. Multiple MavenModuletSets are built 
starting at the same time, and some how the numbering of MavenModules gets out 
of sync.

The commit in 
https://github.com/jyrkiput/jenkins/commit/0d076e610b39b215ed34c35a5d4840e56183d5e4
 fixes this, but I haven't tested it other cases than mine and I don't think 
that I'm qualified to change something that is this deeply on the jenkins core 
:) The commit probably has some unnecessary bits in it too at the moment. So I 
don't think that it should be merged :)

--
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-13811) System Message alignment differs if user is not logged in

[sebastian.moel...@gmx.de (JIRA)]

Sebastian Möller created JENKINS-13811:
--

 Summary: System Message alignment differs if user is not logged in
 Key: JENKINS-13811
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13811
 Project: Jenkins
  Issue Type: Bug
  Components: gui
Affects Versions: current
Reporter: Sebastian Möller
Priority: Trivial
 Attachments: system_message_user_logged_in.png, 
system_message_user_not_logged_in.png

Jenkins Version: 1.464

The white space area between the "System Message" and the panel below is 
missing if the user is not logged in.

See attachments for an example.

--
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-13811) System Message alignment differs if user is not logged in

[smoo...@googlemail.com (JIRA)]

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

Sebastian Möller updated JENKINS-13811:
---

Description: 
Jenkins version: 1.464

The white space area between the "System Message" and the panel below is 
missing if the user is not logged in.

See attachments for an example.

  was:
Jenkins Version: 1.464

The white space area between the "System Message" and the panel below is 
missing if the user is not logged in.

See attachments for an example.


> System Message alignment differs if user is not logged in
> -
>
> Key: JENKINS-13811
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13811
> Project: Jenkins
>  Issue Type: Bug
>  Components: gui
>Affects Versions: current
>Reporter: Sebastian Möller
>Priority: Trivial
> Attachments: system_message_user_logged_in.png, 
> system_message_user_not_logged_in.png
>
>
> Jenkins version: 1.464
> The white space area between the "System Message" and the panel below is 
> missing if the user is not logged in.
> See attachments for an example.

--
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-13549) Duplicate test results are shown for grails projectsgr

[raviteja.lokin...@gmail.com (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162881#comment-162881
 ] 

Ravi Teja Lokineni commented on JENKINS-13549:
--

This started happening recently. Will update that configuration and see.

> Duplicate test results are shown for grails projectsgr
> --
>
> Key: JENKINS-13549
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13549
> Project: Jenkins
>  Issue Type: Bug
>  Components: core, grails
>Reporter: Ravi Teja Lokineni
>Assignee: jeffg2one
>  Labels: grails
> Attachments: dup_tests.png, dup_tests_1.png, dup_tests_1.png
>
>
> This started happening recently. PFA the attached screenshots. Each failed 
> testcase is printed twice.

--
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-9494) Configure System hangs with "LOADING" gray div covering top half of settings

[jenkins...@photono.de (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-9494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162882#comment-162882
 ] 

Andreas Katzig commented on JENKINS-9494:
-

Encountered the same today. Should be possible to fix ...

> Configure System hangs with "LOADING" gray div covering top half of settings
> 
>
> Key: JENKINS-9494
> URL: https://issues.jenkins-ci.org/browse/JENKINS-9494
> Project: Jenkins
>  Issue Type: Bug
>  Components: infrastructure
>Affects Versions: current
> Environment: OpenJDK Runtime Environment (IcedTea6 1.9.7) 
> (6b20-1.9.7-0ubuntu1)
> OpenJDK Client VM (build 19.0-b09, mixed mode, sharing)
> AWS EC2 cloud instance machine
> package installed by the recommended apt-get instructions on jenkins-ci.org. 
> apt-show says:
> "Package: jenkins
> Priority: extra
> Section: devel
> Installed-Size: 37480
> Maintainer: Kohsuke Kawaguchi 
> Architecture: all
> Version: 1.404
> Replaces: hudson
> Depends: daemon, adduser, psmisc, java2-runtime
> Conflicts: hudson
> Filename: binary/jenkins_1.404_all.deb
> Size: 38056418
> MD5sum: 84529c04673ebe58208b4d0820853e54
> SHA1: 1c5df6bd354395edac88e136d9503ee8c92d60f3
> SHA256: 25270ed4f113423754c4fab03e48d13396896d98f087e8980e11e61bd97ff711
> Description: Continuous integration system written in Java
>  Jenkins is an extensible continuous engine written in Java.
> Homepage: https://jenkins-ci.org/
> "
> Note despite this 1.404, Jenkins actually displays 1.407 in its footer
>Reporter: Jay Levitt
>Priority: Critical
>
> I am setting up Jenkins for the first time. I've successfully gone into the 
> configure system screen before, because I was able to set up matrix user 
> permissions as outlined in the Standard Security guide. I wanted to add an 
> environment variable to set the time, but now I'm unable, because the page 
> load never completes. I'm new to java, but happy to troubleshoot and try 
> things if you tell me what logs to look at. This is NOT running under TomCat.

--
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-13737) Javascript error when selecting "Editable Email Notification"

[slide.o....@gmail.com (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162883#comment-162883
 ] 

Slide-O-Mix commented on JENKINS-13737:
---

Then try installing 2.21. It works for me on those versions.

> Javascript error when selecting "Editable Email Notification"
> -
>
> Key: JENKINS-13737
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13737
> Project: Jenkins
>  Issue Type: Bug
>  Components: email-ext
>Affects Versions: current
> Environment: Windows, IE8, Jenkins 1.463, Jenkins Email Extension 
> Plugin 2.20
>Reporter: Noel Bernardez
>Assignee: Slide-O-Mix
>  Labels: email-ext, jenkins
>
> In Jenkins ver. 1.463, when selecting "Editable Email Notification" in the 
> "Add post-build action", getting the following Javascript error 
> Message: 'emailExtInit' is undefined
> Line: 480
> Char: 17
> Code: 0
> URI: http://myserver:8080/static/f11a6618/scripts/hudson-behavior.js

--
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-12421) Add pre-send step to email-ext that can modify the mail message object

[terrylwesterh...@hotmail.com (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-12421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162884#comment-162884
 ] 

terryl westerhold commented on JENKINS-12421:
-

Yes, that is what I was thinking.  I am curious to know how you are thinking 
you will approach this issue though.  Having a feature that specifically 
addressed the claim issue would be great, but I really think the "more 
elaborate solution" I mentioned in my initial post would be much more 
beneficial.  Giving the option to run a "pre-send" script after the message was 
fully built would give me the ability to fix this issue, and the potential to 
do many other things with the MimeMessage before it was sent.

> Add pre-send step to email-ext that can modify the mail message object
> --
>
> Key: JENKINS-12421
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12421
> Project: Jenkins
>  Issue Type: New Feature
>  Components: claim, email-ext
>Affects Versions: current
> Environment: All
>Reporter: terryl westerhold
>Assignee: Slide-O-Mix
>  Labels: claim, email-ext, feature, groovy, jenkins, plugin, 
> script
>
> When the Email-Ext plugin is used in conjunction with the Claim plugin there 
> is no way to configure a project's email options to only send to the one who 
> has claimed it.  This results in every person on a team receiving emails for 
> a build they did not break, turning Jenkins emails into something annoying 
> instead of something useful.  For someone who knew the code this would be a 
> pretty easy feature to add.  And while this would be a good feature, I think 
> a more elaborate solution that would allow Email-ext plugin users to 
> access/modify all parts of the email message (including who the message is 
> being sent to) would be more useful in the long run.  Giving users access to 
> all parts of the email message and the option to run a Groovy script after 
> the email has been built, but before the email has been sent would satisfy 
> this feature request and would make the Email-Ext plugin much more versatile.

--
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-13809) Template variables are permanently overwritten on first use

[j...@joncairns.com (JIRA)]

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

Jon Cairns updated JENKINS-13809:
-

Component/s: memegen
 (was: jenkins-plugin-runtime)

> Template variables are permanently overwritten on first use
> ---
>
> Key: JENKINS-13809
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13809
> Project: Jenkins
>  Issue Type: Bug
>  Components: memegen
>Affects Versions: current
> Environment: Should happen on all systems and versions.
>Reporter: Jon Cairns
>Assignee: Jon Cairns
>  Labels: jenkins, meme
>
> Meme configurations that include template variables such as "${project}" will 
> be overwritten with the actual name of the project that first uses that Meme, 
> as the Meme object is not copied/cloned, and it is automatically saved. The 
> fix is to create a copy of the object and use that for the Meme generation.

--
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-12421) Add pre-send step to email-ext that can modify the mail message object

[slide.o....@gmail.com (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-12421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162885#comment-162885
 ] 

Slide-O-Mix commented on JENKINS-12421:
---

I am planning on adding the groovy feature, I was just wondering where you 
might want to configure it. If only at the project level (not at the global 
level and not at the trigger level) it makes it a bit easier :-)

> Add pre-send step to email-ext that can modify the mail message object
> --
>
> Key: JENKINS-12421
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12421
> Project: Jenkins
>  Issue Type: New Feature
>  Components: claim, email-ext
>Affects Versions: current
> Environment: All
>Reporter: terryl westerhold
>Assignee: Slide-O-Mix
>  Labels: claim, email-ext, feature, groovy, jenkins, plugin, 
> script
>
> When the Email-Ext plugin is used in conjunction with the Claim plugin there 
> is no way to configure a project's email options to only send to the one who 
> has claimed it.  This results in every person on a team receiving emails for 
> a build they did not break, turning Jenkins emails into something annoying 
> instead of something useful.  For someone who knew the code this would be a 
> pretty easy feature to add.  And while this would be a good feature, I think 
> a more elaborate solution that would allow Email-ext plugin users to 
> access/modify all parts of the email message (including who the message is 
> being sent to) would be more useful in the long run.  Giving users access to 
> all parts of the email message and the option to run a Groovy script after 
> the email has been built, but before the email has been sent would satisfy 
> this feature request and would make the Email-Ext plugin much more versatile.

--
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-13812) Include a functionality that lets the user see only Failed tests, or toggle between different views for TAP Results

[brunodepau...@yahoo.com.br (JIRA)]

Bruno P. Kinoshita created JENKINS-13812:


 Summary: Include a functionality that lets the user see only 
Failed tests, or toggle between different views for TAP Results
 Key: JENKINS-13812
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13812
 Project: Jenkins
  Issue Type: Improvement
  Components: tap
Reporter: Bruno P. Kinoshita
Assignee: Bruno P. Kinoshita


>From e-mail: 

>Can we have functionality to see all the FAILs at the top of the TAP output? 
>We are less concerned with all the PASSes. From my perspective, having a way 
>to toggle between the full TAP output and FAILs only would be ideal.
> 
>This becomes important when you find you are paging through many screens of 
>TAP results!

--
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-850) search box should match non-casesensitively

[radek.chr...@gooddata.com (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162886#comment-162886
 ] 

Radek Chromy commented on JENKINS-850:
--

It seems to be platform/environment depended:
Jenkins ver. 1.464
Linux Ubuntu 12.04, Chromium 18.0.1025.151, search is case *insensitive*.
Mac OS X 10.7.3 a Chrome Version 19.0.1084.46, search is case *sensitive*.


> search box should match non-casesensitively
> ---
>
> Key: JENKINS-850
> URL: https://issues.jenkins-ci.org/browse/JENKINS-850
> Project: Jenkins
>  Issue Type: Improvement
>  Components: www
>Affects Versions: current
> Environment: Platform: All, OS: All
>Reporter: gradopado
>Assignee: dogfood
>
> The search box would be even more useful if it would match text 
> non-casesensitively.

--
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-13813) NullPointer after upgrading to 1.6

[lshat...@java.net (JIRA)]

lshatzer created JENKINS-13813:
--

 Summary: NullPointer after upgrading to 1.6
 Key: JENKINS-13813
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13813
 Project: Jenkins
  Issue Type: Bug
  Components: grails
Reporter: lshatzer
Assignee: jeffg2one
Priority: Critical


After upgrading to 1.6, when my Grails jobs run, I get a NPE:
{code}
java.lang.NullPointerException
at com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:155)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at 
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
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:480)
at hudson.model.Run.run(Run.java:1434)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
{code}

I save my job after opening it up and saving it without changing, it now works. 
The config file now has an empty: useWrapper element. Your plugin should 
probably handle it missing without having to resave all grails jobs.

--
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-13809) Template variables are permanently overwritten on first use

[j...@joncairns.com (JIRA)]

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

Work on JENKINS-13809 started by Jon Cairns.

> Template variables are permanently overwritten on first use
> ---
>
> Key: JENKINS-13809
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13809
> Project: Jenkins
>  Issue Type: Bug
>  Components: memegen
>Affects Versions: current
> Environment: Should happen on all systems and versions of Jenkins.
>Reporter: Jon Cairns
>Assignee: Jon Cairns
>  Labels: jenkins, meme
>
> Meme configurations that include template variables such as "${project}" will 
> be overwritten with the actual name of the project that first uses that Meme, 
> as the Meme object is not copied/cloned, and it is automatically saved. The 
> fix is to create a copy of the object and use that for the Meme generation.

--
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-13809) Template variables are permanently overwritten on first use

[j...@joncairns.com (JIRA)]

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

Jon Cairns updated JENKINS-13809:
-

Environment: Should happen on all systems and versions of Jenkins.  (was: 
Should happen on all systems and versions.)

> Template variables are permanently overwritten on first use
> ---
>
> Key: JENKINS-13809
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13809
> Project: Jenkins
>  Issue Type: Bug
>  Components: memegen
>Affects Versions: current
> Environment: Should happen on all systems and versions of Jenkins.
>Reporter: Jon Cairns
>Assignee: Jon Cairns
>  Labels: jenkins, meme
>
> Meme configurations that include template variables such as "${project}" will 
> be overwritten with the actual name of the project that first uses that Meme, 
> as the Meme object is not copied/cloned, and it is automatically saved. The 
> fix is to create a copy of the object and use that for the Meme generation.

--
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-13809) Template variables are permanently overwritten on first use

[j...@joncairns.com (JIRA)]

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

Jon Cairns resolved JENKINS-13809.
--

Resolution: Fixed

Fixed in version 0.4.0.

> Template variables are permanently overwritten on first use
> ---
>
> Key: JENKINS-13809
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13809
> Project: Jenkins
>  Issue Type: Bug
>  Components: memegen
>Affects Versions: current
> Environment: Should happen on all systems and versions of Jenkins.
>Reporter: Jon Cairns
>Assignee: Jon Cairns
>  Labels: jenkins, meme
>
> Meme configurations that include template variables such as "${project}" will 
> be overwritten with the actual name of the project that first uses that Meme, 
> as the Meme object is not copied/cloned, and it is automatically saved. The 
> fix is to create a copy of the object and use that for the Meme generation.

--
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-13809) Template variables are permanently overwritten on first use

[j...@joncairns.com (JIRA)]

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

Jon Cairns updated JENKINS-13809:
-


This is present in all versions up to 0.3.2.

> Template variables are permanently overwritten on first use
> ---
>
> Key: JENKINS-13809
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13809
> Project: Jenkins
>  Issue Type: Bug
>  Components: memegen
>Affects Versions: current
> Environment: Should happen on all systems and versions of Jenkins.
>Reporter: Jon Cairns
>Assignee: Jon Cairns
>  Labels: jenkins, meme
>
> Meme configurations that include template variables such as "${project}" will 
> be overwritten with the actual name of the project that first uses that Meme, 
> as the Meme object is not copied/cloned, and it is automatically saved. The 
> fix is to create a copy of the object and use that for the Meme generation.

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

[ah...@hotmail.com (JIRA)]

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

Amir Isfy commented on JENKINS-13227:
-

I am getting the info on our CVS setup from the IT. In the meantime I can 
confirm that the projects that are polling the Head are fine, detecting changes 
and posting the changes on the web interface.

> 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
> Attachments: rlog.txt
>
>
> 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-13227) CVS plugin 2.1 does not detect changes

[ah...@hotmail.com (JIRA)]

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

Amir Isfy commented on JENKINS-13227:
-

We're using CVSNT 2.5.03
We authenticate using pserver


> 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
> Attachments: rlog.txt
>
>
> 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-8744) Maven cannot run with JDK1.5 anymore

[bruno...@gmail.com (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162891#comment-162891
 ] 

Bruno Medeiros commented on JENKINS-8744:
-

Same error here, on Jenkins 1.463:

{code}
<===[JENKINS REMOTING CAPACITY]===>channel started
log4j:WARN No appenders could be found for logger 
(org.apache.commons.beanutils.converters.BooleanConverter).
log4j:WARN Please initialize the log4j system properly.
channel stopped
ERROR: Failed to parse POMs
java.io.IOException: Remote call on Channel to Maven 
[/var/lib/jenkins/tools/Sun_JDK_1.5/bin/java, -cp, 
/var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven-agent-1.2.jar:/var/lib/jenkins/tools/Maven_2/boot/classworlds-1.1.jar,
 hudson.maven.agent.Main, /var/lib/jenkins/tools/Maven_2, 
/var/cache/jenkins/war/WEB-INF/lib/remoting-2.13.jar, 
/var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven-interceptor-1.2.jar, 
59378, 
/var/lib/jenkins/plugins/maven-plugin/WEB-INF/lib/maven2.1-interceptor-1.2.jar] 
failed
at hudson.remoting.Channel.call(Channel.java:655)
at hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:156)
at 
hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:791)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:480)
at hudson.model.Run.run(Run.java:1434)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
Caused by: java.lang.ClassFormatError: Failed to load 
com.google.common.collect.ImmutableSet
at 
hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:154)
at 
hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:131)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at hudson.security.PermissionScope.(PermissionScope.java:70)
at hudson.security.PermissionScope.(PermissionScope.java:95)
at hudson.security.Permission.(Permission.java:179)
at hudson.security.Permission.(Permission.java:292)
at hudson.model.Run.(Run.java:2038)
at hudson.maven.Maven2Builder.call(Maven2Builder.java:74)
at hudson.maven.Maven2Builder.call(Maven2Builder.java:53)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class 
file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.lang.ClassLoader.defineClass(ClassLoader.java:466)
at 
hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:152)
... 20 more
Finished: FAILURE

{code}

> Maven cannot run with JDK1.5 anymore
> 
>
> Key: JENKINS-8744
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8744
> Project: Jenkins
>  Issue Type: Bug
>  Components: maven2
>Reporter: Rainer Weinhold
>
> Since an update to jenkins 1.395 the maven projects running with an JDK 1.5 
> arent working anymore. 
> The error "Bad version number in .class file" looks like something got 
> compiled with a newer java version. This error happens on a slave with maven 
> 2.0.11 and oracle-jdk 1.5.21. 
> - When i reconfigure the project to oracle-jdk 1.6.20 it works.
> - It also works with java 1.5 when executed directly on den shell. 
> -> The only thing different there is the magic agent stuff.
> So i extracted the jars : maven-interceptor, maven-agent, slave.jar, 
> classworlds. Non of which there seems to be a newer .class version number. 
> Any ideas which files could cause the problem? Pretty sure this is a jenkins 
> issue, otherwise maven wouldn't compile it directly on the build system.
> LOG:
> {noformat}
> At revision 56650
> no change for http://.../trunk since the previous build
> Found mavenVersion 2.0.11 from file 
> jar:file:/srv/hudson/tools/maven-2.0.x/lib/maven-2.0.11-uber.jar!/META-INF/maven/

[JIRA] (JENKINS-13814) java.lang.OutOfMemoryError exception when getting the remote log

[jgustaf...@ecrio.com (JIRA)]

James Gustafson created JENKINS-13814:
-

 Summary: java.lang.OutOfMemoryError exception when getting the 
remote log
 Key: JENKINS-13814
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13814
 Project: Jenkins
  Issue Type: Bug
  Components: cvs
 Environment: Jenkins 1.464 on Windows 7 64-bit, 12GB RAM; CVS Plug-in 
2.4-SNAPSHOT
Reporter: James Gustafson


We are getting a java.lang.OutOfMemoryError exception when getting the remote 
log.

{quote}
Started by an SCM change
Building in workspace C:\x\workspace\project_name_here
cvs checkout -r BRANCH_NAME_HERE -D 16 May 2012 23:27:38 -0700 -d path\projects 
path/projects
cvs checkout: Updating path\projects
cvs checkout: Updating path\projects/dir1
cvs checkout: Updating path\projects/dir2/dirA
... (about 7,224 directories) ...
cvs checkout: Updating path\projects/dirN
cvs rlog: Logging path\projects
... (about 7,224 directories) ...
cvs rlog: Logging path\projects/dirN
FATAL: Java heap space
java.lang.OutOfMemoryError: Java heap space
at java.lang.StringCoding$StringDecoder.decode(Unknown Source)
at java.lang.StringCoding.decode(Unknown Source)
at java.lang.StringCoding.decode(Unknown Source)
at java.lang.String.(Unknown Source)
at java.io.ByteArrayOutputStream.toString(Unknown Source)
at hudson.scm.CVSSCM.getRemoteLogForModule(CVSSCM.java:540)
at hudson.scm.CVSSCM.calculateChangeLog(CVSSCM.java:415)
at hudson.scm.CVSSCM.checkout(CVSSCM.java:825)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
at 
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
at hudson.model.Run.run(Run.java:1434)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
{quote}


Some notes:
- The path/ and path\ comes from the "Remote Name"/"Local Name" settings 
solution from Issue JENKINS-13264
- We are using Jenkins 1.464 with the 2.4-SNAPSHOT version of the CVS plugin, 
but may not have been caused by this specific version
- The arguments setting in the jenkins.xml file currently has -Xms1024m 
(anything larger and Jenkins service won't start)
- The CVS module has many legacy projects spread out, and thus, contains more 
than 7,000 directories and many more files
- Things had worked with the 1.6 plug-in & CVSNT client, but it also 
occasionally timed out getting the changelog, hence our testing of the 2.x 
plug-ins


--
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-13735) Jenkins starts wrong slave for job restricted to specific one

[jsiir...@java.net (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162892#comment-162892
 ] 

jsiirola commented on JENKINS-13735:


I am also seeing this problem after upgrading from 1.459 -> 1.464 (running 
Winstone under Linux).  I do not have the vSphere plugin installed.  In my 
case, the problem is being exacerbated by one of the build slaves being down 
for maintenance.  This has led to jobs stacking up in the queue, which in turn 
has led to Jenkins starting every slave in the farm.

> Jenkins starts wrong slave for job restricted to specific one
> -
>
> Key: JENKINS-13735
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13735
> Project: Jenkins
>  Issue Type: Bug
>  Components: master-slave, slave-setup, vsphere-cloud
>Affects Versions: current
> Environment: Jenkins 1.463 under Tomcat6 on Linux (SLES 11), Windows 
> XP slave VMs controlled via vSphere Cloud plugin
>Reporter: Marco Lehnort
>Assignee: Kohsuke Kawaguchi
>  Labels: slave
>
> I'm using the following setup:
> - WinXP slaves A,B,C
> - jobs jA, jB, jC, tied to slaves A,B,C respectively using "Restrict where 
> this job can run"
> Assume all slaves are disconnected and powered off, no builds are queued.
> When starting a build manually, say jC, the following will happen:
> - job jC will be scheduled and also displayed accordingly in the build queue
> - tooltip will say it's waiting because slave C is offline
> - next, slave A is powered on by Jenkins and connection is established
> - jC will not be started, Jenkins seems to honor the restriction correctly
> - after some idle time, Jenkins realizes the slave is idle and causes shut 
> down
> - then, same procedure happens with slave B
> - on occasion, next one is slave A again
> - finally (on good luck?) slave C happens to be started
> - jC is executed
> It is possible that jC is waiting for hours (indefinitely?), because the 
> required
> slave is not powered on. I also observed this behaviour using a time-trigger
> instead of manual trigger, so I assume it is independent of the type of 
> trigger.
> Occasionally it also happens that the correct slave is powered up right away,
> but that seems to happen by chance. The concrete pattern is not obvious to me.
> Note that the component selection above is just my best guess.
> Cheers, Marco

--
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-12972) Add option to run 'git bisect' to find which commit added new bugs

[bn...@java.net (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-12972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162893#comment-162893
 ] 

bnovc commented on JENKINS-12972:
-

{{git blame}} would be faster, but you would often not get correct results. 
This only works if the problem you're trying to detect was caused by the last 
edit to the line the problem was exposed.

I would really like to see {{git bisect}} offered as part of a normal build 
with the git plugin. That way I would immediately know who broke the build 
definitively. This would save significant time in triaging, as the person 
responsible could be notified automatically.

> Add option to run 'git bisect' to find which commit added new bugs 
> ---
>
> Key: JENKINS-12972
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12972
> Project: Jenkins
>  Issue Type: New Feature
>  Components: analysis-core, core, findbugs, git
>Reporter: Eyal Edri
>Priority: Minor
>
> Today, when you run find-bugs plug-in triggered by a git commit, you can't 
> know exactly which commit added those bugs.
> It becomes especially difficult to know when a high volume of commits is 
> pushed at once.
> find-bugs plug-in could have a new option to tick in the 'advanced section',
> which will do a 'git bisect' on the git commits that caused a new bug and 
> display/email to commiter who did it.
> that would simply and automate the process of finding who wrote the bug.

--
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-13815) scm-sync-configuration raises unexpectedError() loading job configuration in IE8

[jsiir...@java.net (JIRA)]

jsiirola created JENKINS-13815:
--

 Summary: scm-sync-configuration raises unexpectedError() loading 
job configuration in IE8
 Key: JENKINS-13815
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13815
 Project: Jenkins
  Issue Type: Bug
  Components: scm-sync-configuration
 Environment: Jenkins 1.464, scm-sync-configuration 0.0.5, IE8
Reporter: jsiirola
Assignee: Frédéric Camblor


The scm-sync-configuration plugin raises the following alert when loading a job 
configuration using IE8:
{noformat}
Something went wrong with the scm-sync-configuration plugin !
Please report a JIRA with as much informations as possible (browser, os, 
current url, error message etc.).
Error message : Cannot retrieve target form on current page !
{noformat}
This only happens in IE8 (Firefox throws no warning), and if you are accessing 
the job configuration through a View other then the default (All) view.  
Accessing the job through the "All" view does not raise the error.  For 
example, the following does not raise an error:
{noformat}
http://localhost:8080/job/my_test/configure
{noformat}
But this URL does (but only in IE8, not Firefox):
{noformat}
http://localhost:8080/view/Tests/job/my_test/configure
{noformat}



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

From Groovy script, SCM polling reports incorrect info if job makes its own checkins

[Joel S]

I have a bunch of interrelated jobs that do Maven releases.  For various
reasons, they're not using the Jenkins release plugin, but rather invoke mvn
release:prepare release:perform as one of a sequence of steps.  I have all
the jobs linked together using build triggers, so if you run one of these
release jobs, it knows which others depend on it and need to be run
afterward.  Before doing the release, each job updates its pom.xml with the
latest versions released by the previous upstream jobs.

So far so good, that all works perfectly.  But, I wanted to automate one
more piece.  Currently, you have to know which parts of the project have
been updated since the last release, and manually start those releases.  It
seems like all the information is available to Jenkins to figure that out
for me, though.  It knows when each job ran, it has hooks to talk to the SCM
to find out if new changes have been checked in, so a simple Groovy script
should suffice.  But there's a catch.

Maybe this would work with other SCMs, but I'm using svn, and here's what
happens.  When I run one of my release jobs, Jenkins first does an SCM
update to pull down all the changes.  Then it does the release, which checks
in two changes to the pom.xml file.  The state of the workspace has now
changed - the SCM revision that Jenkins originally pulled down isn't the
latest any more, it's been bumped twice.  The workspace knows this, but I
think Jenkins doesn't.  The svn plugin keeps a file around called
revision.txt, and this file appears to be a cache of what revision the
workspace is at.  So, in my Groovy script, when I ask Jenkins whether that
job has SCM changes, and therefore needs to be run, Jenkins always answers
yes.  This is because it's looking at revision.txt to figure out if the
workspace needs updating, and revision.txt is out of date -- it still thinks
the workspace doesn't have the two changes committed during the release.  My
Groovy script looks like this:

job = 
def latestBuild = job.getLastCompletedBuild();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
def listener = new hudson.model.StreamBuildListener(baos);
def launcher = new hudson.Launcher.LocalLauncher(listener);
def scmrev = job.scm.calcRevisionsFromBuild(latestBuild, launcher,
listener);
def pollingResult = job.scm.compareRemoteRevisionWith(job, launcher,
job.workspace, listener, scmrev);
return pollingResult.hasChanges();

I've tried to force the workspace to do a checkout, to update revision.txt,
but ironically, that takes the workspace backward in time.  Here's the
script I'm using:

job = 
def latestBuild = job.getLastCompletedBuild();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
def listener = new hudson.model.StreamBuildListener(baos);
def launcher = new hudson.Launcher.LocalLauncher(listener);
job.scm.checkout(latestBuild, launcher, job.workspace, listener,
File.createTempFile("tempcheckout", "txt"));

When it runs, it decides for some reason to refresh the workspace to the
state described in revision.txt, rather than the state in the depot.

So, I'm hoping someone can tell me that I'm just looking at this the wrong
way, and there's a simple thing I can do to force revision.txt to get
updated after the mvn release finishes.  Or maybe there's some other way to
invoke checkout so that it updates revision.txt to match the workspace,
rather than the other way around.  Thanks.

-Joel


--
View this message in context: 
http://jenkins.361315.n4.nabble.com/From-Groovy-script-SCM-polling-reports-incorrect-info-if-job-makes-its-own-checkins-tp4628884.html
Sent from the Jenkins issues mailing list archive at Nabble.com.

[JIRA] (JENKINS-13816) Refactor hundson.MarkupText to allow replacing entire HTML body

[dbl...@dblock.org (JIRA)]

Daniel Doubrovkine created JENKINS-13816:


 Summary: Refactor hundson.MarkupText to allow replacing entire 
HTML body
 Key: JENKINS-13816
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13816
 Project: Jenkins
  Issue Type: Improvement
  Components: core
Reporter: Daniel Doubrovkine
Priority: Minor


The implementation of AnsiColor is quite hacky. It needs to replace the entire 
body of text with html (translates ansi codes that can appear anywhere inside 
the text to html). Unfortunately MarkupText only lets you markup the text by 
inserting tags in different locations, which is not practical at all since we 
need to delete existing text and insert tags all over the place.

I'd like to see MarkupText refactored to allow complete replacement of the data 
with unencoded html. For starters, maybe a clearText() could get the job done? 
Generally, markuptext is trying to be too smart about markup. 

Another option could be an extension point that lets me replace the text stream 
with html (unencoded).

Refactor core/src/main/java/hudson/MarkupText.java
https://github.com/dblock/jenkins-ansicolor-plugin

--
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-13817) Jenkins Displays Accurev Password in Logs

[timothy.johns...@kronos.com (JIRA)]

tim johnston created JENKINS-13817:
--

 Summary: Jenkins Displays Accurev Password in Logs
 Key: JENKINS-13817
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13817
 Project: Jenkins
  Issue Type: Bug
  Components: accurev
Affects Versions: current
 Environment: windows
Reporter: tim johnston
Assignee: Scott Tatum


When an accurev command fails, it displays the users' password in plain text. 
You can see below that the password is properly obscured (with asterisks) when 
the authentication takes place. 

Unfortunately, the password is actually displayed in the fatal network error 
line. Note that I manually changed it to  when I pasted the text into this 
bug report.

Error text:

Started by user anonymous
Building remotely on TestReport in workspace 
D:\jenkins-slave\workspace\Test_Report_06_04_00_Budgeting_kvh223_WFOP_Macys_ora
Purging workspace...
Workspace purged.
Setting ACCUREV_HOME to "D:\jenkins-slave\workspace"
Authenticating with Accurev server...
[Test_Report_06_04_00_Budgeting_kvh223_WFOP_Macys_ora] $ "C:\Program Files 
(x86)\AccuRev\bin\accurev.exe" login -H engaccurev:5051 tim.johnston 
FATAL: network error - Can't connect to engaccurev.kronos.com for accurev: The 
operation completed successfully. 
Attempt to contact AccuRev server on engaccurev port 5051 failed.
Giving up.
AccuRev Error: 1

FATAL: login ("C:\Program Files (x86)\AccuRev\bin\accurev.exe" login -H 
engaccurev:5051 tim.johnston ^^^) failed with exit code 1
Archiving artifacts
Recording test results
Notifying upstream projects of job completion
Finished: FAILURE

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

[pradeep.pa...@ericsson.com (JIRA)]

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

Pradeep Patil commented on JENKINS-13227:
-

I have been following this issue and I am also having similar problems .. in my 
case when I upgraded the plugin a lot of my builds started getting kicked off 
regularly like every hour .. and the version number are getting tagged every 
time a new build is kicked off which is supposed to happen only when new 
changes are found. so basically the builds are happening even when there are no 
changes and version tags are getting incremented.


This is the cvs polling log found in every build kicked every hour .. 

Started on May 17, 2012 3:00:33 PM
cvs rlog: Logging lscpproxy-java
cvs rlog: Logging lscpproxy-java/bin
cvs rlog: Logging lscpproxy-java/build
cvs rlog: Logging lscpproxy-java/conf
cvs rlog: Logging lscpproxy-java/lib
cvs rlog: Logging lscpproxy-java/mib
cvs rlog: Logging lscpproxy-java/scripts
cvs rlog: Logging lscpproxy-java/src
cvs rlog: Logging lscpproxy-java/src/com
cvs rlog: Logging lscpproxy-java/src/com/n2bb
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/C1Udp
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/db
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/exceptions
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/injection
cvs rlog: Logging lscpproxy-java/src/com/n2bb/lscpproxy/monitoring
cvs rlog: Logging lscpproxy-java/src/main
cvs rlog: Logging lscpproxy-java/src/main/xml
cvs rlog: Logging lscpproxy-java/test
cvs rlog: Logging lscpproxy-java/test/scripts
cvs rlog: Logging lscpproxy-java/test/src
cvs rlog: Logging lscpproxy-java/test/src/com
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/db
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/http
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/http/testServer
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/lsc
cvs rlog: Logging lscpproxy-java/test/src/com/n2bb/lscpproxy/rtsp
Done. Took 0.32 sec
Changes found


I also get a lot of rlog errors like this :

java.lang.RuntimeException: Error while trying to run CVS rlog
at hudson.scm.CVSSCM.getRemoteLogForModule(CVSSCM.java:523)
at hudson.scm.CVSSCM.calculateRepositoryState(CVSSCM.java:459)
at hudson.scm.CVSSCM.compareRemoteRevisionWith(CVSSCM.java:320)
at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356)
at hudson.scm.SCM.poll(SCM.java:373)
at hudson.model.AbstractProject.poll(AbstractProject.java:1346)
at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420)
at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449)
at 
hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

Can someone help ? I have tried to delte the projects and recreate them on 
jenkins and its not helping .. they are still getting triggered every hour .. 

> 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
> Attachments: rlog.txt
>
>
> 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 checkou

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

[guillaume.bilod...@gmail.com (JIRA)]

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

Guillaume Bilodeau commented on JENKINS-13227:
--

Client: Concurrent Versions System (CVSNT) 2.0.4 (client/server)
Server: Concurrent Versions System (CVS) 1.11.22-FCDQ_LEGO-2.2 (client/server)
Authenticating with pserver

(yes the server version appears to be customized but I've been guaranteed that 
the original sources were compiled and only the binary name has been changed)

I confirm that polling detects changes when run against the CVS head.

Thanks!


> 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
> Attachments: rlog.txt
>
>
> 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

Re: [JIRA] Updated: (JENKINS-2337) CVSTag plugin does not work for Branches - only HEAD

[yjl]

CVS tagging plugin is not working fro CVS plugin 2.0 or later. When will it
be fixed?

--
View this message in context: 
http://jenkins.361315.n4.nabble.com/JIRA-Updated-JENKINS-2337-CVSTag-plugin-does-not-work-for-Branches-only-HEAD-tp3497378p4628893.html
Sent from the Jenkins issues mailing list archive at Nabble.com.

[JIRA] (JENKINS-13818) Jelly f:combobox controls not triggering 'change' events

[char...@talibard.com (JIRA)]

Charles Talibard created JENKINS-13818:
--

 Summary: Jelly f:combobox controls not triggering 'change' events
 Key: JENKINS-13818
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13818
 Project: Jenkins
  Issue Type: Bug
  Components: core
Affects Versions: current
Reporter: Charles Talibard
Priority: Minor


When using jelly f:combobox controls, if a user selects a valid value from the 
list either using the keyboard or mouse, the browser doesn't fire either 
old-style onchange() or new DOM 2 change events. This means that the validation 
doCheckXyz() method isn't called for the new value and subsequent comboboxes 
whose doFillXyzItems() depend on the new value don't fire.

--
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-13818) Jelly f:combobox controls not triggering 'change' events

[char...@talibard.com (JIRA)]

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

Charles Talibard updated JENKINS-13818:
---

Labels: gui jelly jenkins  (was: gui jenkins)

> Jelly f:combobox controls not triggering 'change' events
> 
>
> Key: JENKINS-13818
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13818
> Project: Jenkins
>  Issue Type: Bug
>  Components: core
>Affects Versions: current
>Reporter: Charles Talibard
>Priority: Minor
>  Labels: gui, jelly, jenkins
>
> When using jelly f:combobox controls, if a user selects a valid value from 
> the list either using the keyboard or mouse, the browser doesn't fire either 
> old-style onchange() or new DOM 2 change events. This means that the 
> validation doCheckXyz() method isn't called for the new value and subsequent 
> comboboxes whose doFillXyzItems() depend on the new value don't fire.

--
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-7692) Compilation failure - duplicate case label

[ever...@free.fr (JIRA)]

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

evernat resolved JENKINS-7692.
--

Resolution: Not A Defect

> Compilation failure - duplicate case label
> --
>
> Key: JENKINS-7692
> URL: https://issues.jenkins-ci.org/browse/JENKINS-7692
> Project: Jenkins
>  Issue Type: Bug
>  Components: maven2
> Environment: Hudson-1.359,
> file.encoding UTF-8
> java.version  1.6.0_18
> os.name   Linux
>Reporter: vishaljain000
> Attachments: test.java
>
>
> Hi,
> We are using Hudson ver. 1.359 for build automation. One of our job giving 
> Compilation error as shown in below logs.. Attaching herewith the part file 
> where we face the issue of duplicate case label with "case" statements.
> FYI.. we are using "clean install" as goal & options in hudson configuration.
> 
> {code}
> HUDSON] Archiving 
> /appdata1/javaci/hudson/jobs/IPMR/workspace/IpmrCore/pom.xml to 
> /appdata1/javaci/hudson/jobs/IPMR/modules/se.volvo.it.tdm.ipmr$IpmrCore/builds/2010-09-24_15-57-00/archive/se.volvo.it.tdm.ipmr/IpmrCore/1.0-SNAPSHOT/pom.xml
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] Compilation failure
> /file/location///ipmr/util/IpmrUtil.java:[679,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[682,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[685,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[688,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[691,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[694,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[697,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[700,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[703,4] duplicate case label
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.BuildFailureException: Compilation failure
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>   at 
> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>   at hudson.maven.agent.Main.launch(Main.java:165)
>   at hudson.maven.MavenBuilder.call(MavenBuilder.java:165)
>   at 
> hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:696)
>   at 
> hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:640)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:114)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>   at hudson.remoting.Request$2.run(Request.java:270)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:619)
> Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation 
> failure
>   at 
> org.apache.maven.plugin.AbstractCompilerMojo.execut

[JIRA] (JENKINS-7692) Compilation failure - duplicate case label

[ever...@free.fr (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162896#comment-162896
 ] 

evernat commented on JENKINS-7692:
--

This is a java compilation problem so this is certainly not a Jenkins issue.

In your case you should compile the source files with UTF-8.
When using Maven, add the following for the maven-compiler-plugin in your 
pom.xml:

UTF-8



> Compilation failure - duplicate case label
> --
>
> Key: JENKINS-7692
> URL: https://issues.jenkins-ci.org/browse/JENKINS-7692
> Project: Jenkins
>  Issue Type: Bug
>  Components: maven2
> Environment: Hudson-1.359,
> file.encoding UTF-8
> java.version  1.6.0_18
> os.name   Linux
>Reporter: vishaljain000
> Attachments: test.java
>
>
> Hi,
> We are using Hudson ver. 1.359 for build automation. One of our job giving 
> Compilation error as shown in below logs.. Attaching herewith the part file 
> where we face the issue of duplicate case label with "case" statements.
> FYI.. we are using "clean install" as goal & options in hudson configuration.
> 
> {code}
> HUDSON] Archiving 
> /appdata1/javaci/hudson/jobs/IPMR/workspace/IpmrCore/pom.xml to 
> /appdata1/javaci/hudson/jobs/IPMR/modules/se.volvo.it.tdm.ipmr$IpmrCore/builds/2010-09-24_15-57-00/archive/se.volvo.it.tdm.ipmr/IpmrCore/1.0-SNAPSHOT/pom.xml
> [INFO] 
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] Compilation failure
> /file/location///ipmr/util/IpmrUtil.java:[679,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[682,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[685,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[688,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[691,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[694,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[697,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[700,4] duplicate case label
> /file/location///ipmr/util/IpmrUtil.java:[703,4] duplicate case label
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.BuildFailureException: Compilation failure
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>   at 
> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>   at hudson.maven.agent.Main.launch(Main.java:165)
>   at hudson.maven.MavenBuilder.call(MavenBuilder.java:165)
>   at 
> hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:696)
>   at 
> hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:640)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:114)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>   at hudson.remoting.Request$2.run(Request.java:270)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

[JIRA] (JENKINS-13617) 64-bit java.lang.OutOfMemoryError: PermGen space

[wgrace...@java.net (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162897#comment-162897
 ] 

wgracelee commented on JENKINS-13617:
-

We're getting this error at least once per day after we upgraded to 1.463. In 
its previous version, 1.456, we hardly saw it. The underneath os is Centos 5.5, 
64bit.

> 64-bit java.lang.OutOfMemoryError: PermGen space
> 
>
> Key: JENKINS-13617
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13617
> Project: Jenkins
>  Issue Type: Bug
>  Components: core
>Affects Versions: current
> Environment: CentOS 5.6 64 bit, Java Hotspot 1.6.0.26 
> /usr/lib/jvm/java-1.6.0/bin/java -Dcom.sun.akuma.Daemon=daemonized 
> -Djava.awt.headless=true -DJENKINS_HOME=/var/lib/jenkins -jar 
> /usr/lib/jenkins/jenkins.war -XX:PermSize=512M 
> --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war 
> --daemon --httpPort=8080 --ajp13Port=8009 --debug=5 --handlerCountMax=100 
> --handlerCountMaxIdle=20
>Reporter: Adam Sloan
>  Labels: jenkins, memory, memory-leak, permgen
>
> Even with -XX:PermSize=512M I still get java.lang.OutOfMemoryError: PermGen 
> space about once a day with light load. Our 32-bit Jenkins has never had this 
> problem and no special settings. Memory leak?
> Apr 26, 2012 9:56:34 AM winstone.Logger logInternal
> WARNING: Untrapped Error in Servlet
> java.lang.OutOfMemoryError: PermGen space
> at java.lang.Throwable.getStackTraceElement(Native Method)
> at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
> at java.lang.Throwable.printStackTraceAsCause(Throwable.java:529)
> at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
> at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
> at java.lang.Throwable.printStackTrace(Throwable.java:516)
> at 
> net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:224)
> at 
> net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:171)
> at 
> net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
> at 
> org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)
> at 
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> at 
> hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
> at 
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> at 
> hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at 
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
> at 
> hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
> at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at 
> hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
> at 
> winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215)
> at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> Apr 26, 2012 9:56:37 AM winstone.Logger logInternal
> WARNING: Untrapped Error in Servlet
> java.lang.OutOfMemoryError: PermGen space
> Apr 26, 2012 9:56:50 AM hudson.triggers.SafeTimerTask run
> SEVERE: Timer task hudson.model.LoadStatistics$LoadStatisticsUpdater@2b1c2043 
> failed
> java.lang.OutOfMemoryError: PermGen space

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

[pradeep.pa...@ericsson.com (JIRA)]

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

Pradeep Patil commented on JENKINS-13227:
-

I tested it with the new plugin (2.4-SNAPSHOT (private-05/15/2012 
16:22-hudson)). In The first project that was kicked off after polling for 
changes it went ahead and started checking out the entire cvs repository.

Here is sample cvs command ..
Started by an SCM change
Building on master in workspace /buildpool/jenkins/jobs/logClient-HEAD/workspace
cvs update -d -P -r HEAD -D 17 May 2012 17:22:54 -0400 workspace 
cvs update: Updating ...

This happened while testing with a new project on Jenkins and also on a old 
project on Jenkins. Both of the project were pointing to HEAD.

> 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
> Attachments: rlog.txt
>
>
> 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-13617) 64-bit java.lang.OutOfMemoryError: PermGen space

[wgrace...@java.net (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162899#comment-162899
 ] 

wgracelee commented on JENKINS-13617:
-

And our Jenkins is being run as:
java -XX:NewSize=256m -XX:MaxNewSize=256m -XX:SurvivorRatio=8 
-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled 
-XX:+CMSClassUnloadingEnabled -Xms... -Xmx... -jar ...

> 64-bit java.lang.OutOfMemoryError: PermGen space
> 
>
> Key: JENKINS-13617
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13617
> Project: Jenkins
>  Issue Type: Bug
>  Components: core
>Affects Versions: current
> Environment: CentOS 5.6 64 bit, Java Hotspot 1.6.0.26 
> /usr/lib/jvm/java-1.6.0/bin/java -Dcom.sun.akuma.Daemon=daemonized 
> -Djava.awt.headless=true -DJENKINS_HOME=/var/lib/jenkins -jar 
> /usr/lib/jenkins/jenkins.war -XX:PermSize=512M 
> --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war 
> --daemon --httpPort=8080 --ajp13Port=8009 --debug=5 --handlerCountMax=100 
> --handlerCountMaxIdle=20
>Reporter: Adam Sloan
>  Labels: jenkins, memory, memory-leak, permgen
>
> Even with -XX:PermSize=512M I still get java.lang.OutOfMemoryError: PermGen 
> space about once a day with light load. Our 32-bit Jenkins has never had this 
> problem and no special settings. Memory leak?
> Apr 26, 2012 9:56:34 AM winstone.Logger logInternal
> WARNING: Untrapped Error in Servlet
> java.lang.OutOfMemoryError: PermGen space
> at java.lang.Throwable.getStackTraceElement(Native Method)
> at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
> at java.lang.Throwable.printStackTraceAsCause(Throwable.java:529)
> at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
> at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
> at java.lang.Throwable.printStackTrace(Throwable.java:516)
> at 
> net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:224)
> at 
> net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:171)
> at 
> net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
> at 
> org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)
> at 
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> at 
> hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
> at 
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> at 
> hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at 
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
> at 
> hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
> at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at 
> hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
> at 
> winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215)
> at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> Apr 26, 2012 9:56:37 AM winstone.Logger logInternal
> WARNING: Untrapped Error in Servlet
> java.lang.OutOfMemoryError: PermGen space
> Apr 26, 2012 9:56:50 AM hudson.triggers.SafeTimerTask run
> SEVERE: Timer task hudson.model.LoadStatistics$LoadStatisticsUpdater@2b1c2043 
> failed
> java.lang.OutOfMemoryError: PermGen space

--
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-13617) 64-bit java.lang.OutOfMemoryError: PermGen space

[ever...@free.fr (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162900#comment-162900
 ] 

evernat commented on JENKINS-13617:
---

and you have not set MaxPermSize?


> 64-bit java.lang.OutOfMemoryError: PermGen space
> 
>
> Key: JENKINS-13617
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13617
> Project: Jenkins
>  Issue Type: Bug
>  Components: core
>Affects Versions: current
> Environment: CentOS 5.6 64 bit, Java Hotspot 1.6.0.26 
> /usr/lib/jvm/java-1.6.0/bin/java -Dcom.sun.akuma.Daemon=daemonized 
> -Djava.awt.headless=true -DJENKINS_HOME=/var/lib/jenkins -jar 
> /usr/lib/jenkins/jenkins.war -XX:PermSize=512M 
> --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war 
> --daemon --httpPort=8080 --ajp13Port=8009 --debug=5 --handlerCountMax=100 
> --handlerCountMaxIdle=20
>Reporter: Adam Sloan
>  Labels: jenkins, memory, memory-leak, permgen
>
> Even with -XX:PermSize=512M I still get java.lang.OutOfMemoryError: PermGen 
> space about once a day with light load. Our 32-bit Jenkins has never had this 
> problem and no special settings. Memory leak?
> Apr 26, 2012 9:56:34 AM winstone.Logger logInternal
> WARNING: Untrapped Error in Servlet
> java.lang.OutOfMemoryError: PermGen space
> at java.lang.Throwable.getStackTraceElement(Native Method)
> at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
> at java.lang.Throwable.printStackTraceAsCause(Throwable.java:529)
> at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
> at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
> at java.lang.Throwable.printStackTrace(Throwable.java:516)
> at 
> net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:224)
> at 
> net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:171)
> at 
> net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
> at 
> org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)
> at 
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> at 
> hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
> at 
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> at 
> hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at 
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
> at 
> hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
> at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at 
> hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
> at 
> winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215)
> at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> Apr 26, 2012 9:56:37 AM winstone.Logger logInternal
> WARNING: Untrapped Error in Servlet
> java.lang.OutOfMemoryError: PermGen space
> Apr 26, 2012 9:56:50 AM hudson.triggers.SafeTimerTask run
> SEVERE: Timer task hudson.model.LoadStatistics$LoadStatisticsUpdater@2b1c2043 
> failed
> java.lang.OutOfMemoryError: PermGen space

--
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-6565) Hudson stuck on inexistent job

[klei...@gmail.com (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-6565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162901#comment-162901
 ] 

Kyle Leinen commented on JENKINS-6565:
--

I am also seeing this.  The job cannot be cleared/cancelled without restarting 
Jenkins completely, which is a pain.

> Hudson stuck on inexistent job
> --
>
> Key: JENKINS-6565
> URL: https://issues.jenkins-ci.org/browse/JENKINS-6565
> Project: Jenkins
>  Issue Type: Bug
>  Components: locks-and-latches
>Reporter: rombert
>Assignee: stephenconnolly
>Priority: Blocker
> Attachments: hudon-stuck-system-information.txt, 
> hudson-stuck-enabled-plugins.txt, hudson-stuck-executors.png, 
> hudson-stuck-home-page-queue.png, hudson-stuck-thread-dump.txt
>
>
> After a couple of days, Hudson seems to see a a 'phantom' build queued , 
> which does not execute at all, but it blocks the next job from running. The 
> currently executing build is 'Collectors' and the stuck build is 
> 'SportsEngine-Collection' . The stuck build is a Maven2 build, using the 
> locks-and-latches plugin, polling SVN every minute.

--
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-13815) scm-sync-configuration raises unexpectedError() loading job configuration in IE8

[fcamb...@java.net (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162902#comment-162902
 ] 

Frédéric Camblor commented on JENKINS-13815:


Thanks for your detailed feedback ! :)

Will try to fix this ASAP !

> scm-sync-configuration raises unexpectedError() loading job configuration in 
> IE8
> 
>
> Key: JENKINS-13815
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13815
> Project: Jenkins
>  Issue Type: Bug
>  Components: scm-sync-configuration
> Environment: Jenkins 1.464, scm-sync-configuration 0.0.5, IE8
>Reporter: jsiirola
>Assignee: Frédéric Camblor
>
> The scm-sync-configuration plugin raises the following alert when loading a 
> job configuration using IE8:
> {noformat}
> Something went wrong with the scm-sync-configuration plugin !
> Please report a JIRA with as much informations as possible (browser, os, 
> current url, error message etc.).
> Error message : Cannot retrieve target form on current page !
> {noformat}
> This only happens in IE8 (Firefox throws no warning), and if you are 
> accessing the job configuration through a View other then the default (All) 
> view.  Accessing the job through the "All" view does not raise the error.  
> For example, the following does not raise an error:
> {noformat}
> http://localhost:8080/job/my_test/configure
> {noformat}
> But this URL does (but only in IE8, not Firefox):
> {noformat}
> http://localhost:8080/view/Tests/job/my_test/configure
> {noformat}

--
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-13617) 64-bit java.lang.OutOfMemoryError: PermGen space

[wgrace...@java.net (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162903#comment-162903
 ] 

wgracelee commented on JENKINS-13617:
-

Nop. I'll set it to 512m to see how it turned out.

> 64-bit java.lang.OutOfMemoryError: PermGen space
> 
>
> Key: JENKINS-13617
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13617
> Project: Jenkins
>  Issue Type: Bug
>  Components: core
>Affects Versions: current
> Environment: CentOS 5.6 64 bit, Java Hotspot 1.6.0.26 
> /usr/lib/jvm/java-1.6.0/bin/java -Dcom.sun.akuma.Daemon=daemonized 
> -Djava.awt.headless=true -DJENKINS_HOME=/var/lib/jenkins -jar 
> /usr/lib/jenkins/jenkins.war -XX:PermSize=512M 
> --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war 
> --daemon --httpPort=8080 --ajp13Port=8009 --debug=5 --handlerCountMax=100 
> --handlerCountMaxIdle=20
>Reporter: Adam Sloan
>  Labels: jenkins, memory, memory-leak, permgen
>
> Even with -XX:PermSize=512M I still get java.lang.OutOfMemoryError: PermGen 
> space about once a day with light load. Our 32-bit Jenkins has never had this 
> problem and no special settings. Memory leak?
> Apr 26, 2012 9:56:34 AM winstone.Logger logInternal
> WARNING: Untrapped Error in Servlet
> java.lang.OutOfMemoryError: PermGen space
> at java.lang.Throwable.getStackTraceElement(Native Method)
> at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
> at java.lang.Throwable.printStackTraceAsCause(Throwable.java:529)
> at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
> at java.lang.Throwable.printStackTraceAsCause(Throwable.java:545)
> at java.lang.Throwable.printStackTrace(Throwable.java:516)
> at 
> net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:224)
> at 
> net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:171)
> at 
> net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
> at 
> org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)
> at 
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> at 
> hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
> at 
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> at 
> hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at 
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
> at 
> hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
> at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at 
> hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
> at 
> winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215)
> at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> Apr 26, 2012 9:56:37 AM winstone.Logger logInternal
> WARNING: Untrapped Error in Servlet
> java.lang.OutOfMemoryError: PermGen space
> Apr 26, 2012 9:56:50 AM hudson.triggers.SafeTimerTask run
> SEVERE: Timer task hudson.model.LoadStatistics$LoadStatisticsUpdater@2b1c2043 
> failed
> java.lang.OutOfMemoryError: PermGen space

--
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-13813) NullPointer after upgrading to 1.6

[kiy0t...@java.net (JIRA)]

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

kiy0taka reassigned JENKINS-13813:
--

Assignee: kiy0taka  (was: jeffg2one)

> NullPointer after upgrading to 1.6
> --
>
> Key: JENKINS-13813
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13813
> Project: Jenkins
>  Issue Type: Bug
>  Components: grails
>Reporter: lshatzer
>Assignee: kiy0taka
>Priority: Critical
>
> After upgrading to 1.6, when my Grails jobs run, I get a NPE:
> {code}
> java.lang.NullPointerException
>   at com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:155)
>   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
>   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:480)
>   at hudson.model.Run.run(Run.java:1434)
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
>   at hudson.model.ResourceController.execute(ResourceController.java:88)
>   at hudson.model.Executor.run(Executor.java:239)
> {code}
> I save my job after opening it up and saving it without changing, it now 
> works. The config file now has an empty: useWrapper element. Your plugin 
> should probably handle it missing without having to resave all grails jobs.

--
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-13813) NullPointer after upgrading to 1.6

[kiy0t...@java.net (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162904#comment-162904
 ] 

kiy0taka commented on JENKINS-13813:


If you want to fix this problem now, please run script via Script Console 
(http://yourjenkins/script).
{code}
import hudson.model.*
import com.g2one.hudson.grails.GrailsBuilder

Hudson.instance.items.each { item ->
item.builders.findAll { it in GrailsBuilder && it.useWrapper == null } 
.each {
it.useWrapper = false
item.save()
}
}
{code}

> NullPointer after upgrading to 1.6
> --
>
> Key: JENKINS-13813
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13813
> Project: Jenkins
>  Issue Type: Bug
>  Components: grails
>Reporter: lshatzer
>Assignee: kiy0taka
>Priority: Critical
>
> After upgrading to 1.6, when my Grails jobs run, I get a NPE:
> {code}
> java.lang.NullPointerException
>   at com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:155)
>   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
>   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:480)
>   at hudson.model.Run.run(Run.java:1434)
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
>   at hudson.model.ResourceController.execute(ResourceController.java:88)
>   at hudson.model.Executor.run(Executor.java:239)
> {code}
> I save my job after opening it up and saving it without changing, it now 
> works. The config file now has an empty: useWrapper element. Your plugin 
> should probably handle it missing without having to resave all grails jobs.

--
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-13813) NullPointer after upgrading to 1.6

[scm_issue_l...@java.net (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-13813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162905#comment-162905
 ] 

SCM/JIRA link daemon commented on JENKINS-13813:


Code changed in jenkins
User: kiy0taka
Path:
 src/main/java/com/g2one/hudson/grails/GrailsBuilder.java
http://jenkins-ci.org/commit/grails-plugin/9236327cd1096b6ca821270fdd7ee931a44c8efb
Log:
  fix bug. refs JENKINS-13813






> NullPointer after upgrading to 1.6
> --
>
> Key: JENKINS-13813
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13813
> Project: Jenkins
>  Issue Type: Bug
>  Components: grails
>Reporter: lshatzer
>Assignee: kiy0taka
>Priority: Critical
>
> After upgrading to 1.6, when my Grails jobs run, I get a NPE:
> {code}
> java.lang.NullPointerException
>   at com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:155)
>   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
>   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:480)
>   at hudson.model.Run.run(Run.java:1434)
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
>   at hudson.model.ResourceController.execute(ResourceController.java:88)
>   at hudson.model.Executor.run(Executor.java:239)
> {code}
> I save my job after opening it up and saving it without changing, it now 
> works. The config file now has an empty: useWrapper element. Your plugin 
> should probably handle it missing without having to resave all grails jobs.

--
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-13813) NullPointer after upgrading to 1.6

[kiy0t...@java.net (JIRA)]

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

kiy0taka resolved JENKINS-13813.


Resolution: Fixed

> NullPointer after upgrading to 1.6
> --
>
> Key: JENKINS-13813
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13813
> Project: Jenkins
>  Issue Type: Bug
>  Components: grails
>Reporter: lshatzer
>Assignee: kiy0taka
>Priority: Critical
>
> After upgrading to 1.6, when my Grails jobs run, I get a NPE:
> {code}
> java.lang.NullPointerException
>   at com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:155)
>   at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
>   at 
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
>   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:480)
>   at hudson.model.Run.run(Run.java:1434)
>   at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
>   at hudson.model.ResourceController.execute(ResourceController.java:88)
>   at hudson.model.Executor.run(Executor.java:239)
> {code}
> I save my job after opening it up and saving it without changing, it now 
> works. The config file now has an empty: useWrapper element. Your plugin 
> should probably handle it missing without having to resave all grails jobs.

--
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-8744) Maven cannot run with JDK1.5 anymore

[s.sog...@gmail.com (JIRA)]

[ 
https://issues.jenkins-ci.org/browse/JENKINS-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162906#comment-162906
 ] 

sogabe commented on JENKINS-8744:
-

@Bruno Updating to 1.464 will help you. See JENKINS-13659 

> Maven cannot run with JDK1.5 anymore
> 
>
> Key: JENKINS-8744
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8744
> Project: Jenkins
>  Issue Type: Bug
>  Components: maven2
>Reporter: Rainer Weinhold
>
> Since an update to jenkins 1.395 the maven projects running with an JDK 1.5 
> arent working anymore. 
> The error "Bad version number in .class file" looks like something got 
> compiled with a newer java version. This error happens on a slave with maven 
> 2.0.11 and oracle-jdk 1.5.21. 
> - When i reconfigure the project to oracle-jdk 1.6.20 it works.
> - It also works with java 1.5 when executed directly on den shell. 
> -> The only thing different there is the magic agent stuff.
> So i extracted the jars : maven-interceptor, maven-agent, slave.jar, 
> classworlds. Non of which there seems to be a newer .class version number. 
> Any ideas which files could cause the problem? Pretty sure this is a jenkins 
> issue, otherwise maven wouldn't compile it directly on the build system.
> LOG:
> {noformat}
> At revision 56650
> no change for http://.../trunk since the previous build
> Found mavenVersion 2.0.11 from file 
> jar:file:/srv/hudson/tools/maven-2.0.x/lib/maven-2.0.11-uber.jar!/META-INF/maven/org.apache.maven/maven-core/pom.properties
> No emails were triggered.
> Parsing POMs
> [maven-versioninfo-plugin] $ /srv/hudson/tools/Java-1.5.x/bin/java -Xmx512m 
> -Xms64m -XX:PermSize=64m -XX:MaxPermSize=128m -cp 
> /srv/hudson/maven-agent.jar:/srv/hudson/classworlds.jar 
> hudson.maven.agent.Main /srv/hudson/tools/maven-2.0.x /srv/hudson/slave.jar 
> /srv/hudson/maven-interceptor.jar 44373
> <===[HUDSON REMOTING CAPACITY]===>���channel started
> channel stopped
> ERROR: POMs konnten nicht geparst werden
> java.io.IOException: Remote call on Channel to Maven 
> [/srv/hudson/tools/Java-1.5.x/bin/java, -Xmx512m, -Xms64m, -XX:PermSize=64m, 
> -XX:MaxPermSize=128m, -cp, 
> /srv/hudson/maven-agent.jar:/srv/hudson/classworlds.jar, 
> hudson.maven.agent.Main, /srv/hudson/tools/maven-2.0.x, 
> /srv/hudson/slave.jar, /srv/hudson/maven-interceptor.jar, 44373] failed
>   at hudson.remoting.Channel.call(Channel.java:638)
>   at hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:156)
>   at 
> hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:665)
>   at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:420)
>   at hudson.model.Run.run(Run.java:1362)
>   at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:424)
>   at hudson.model.ResourceController.execute(ResourceController.java:88)
>   at hudson.model.Executor.run(Executor.java:145)
> Caused by: java.lang.UnsupportedClassVersionError: Bad version number in 
> .class file
>   at java.lang.ClassLoader.defineClass1(Native Method)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
>   at 
> hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:151)
>   at 
> hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:131)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>   at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>   at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>   at 
> hudson.plugins.cobertura.MavenCoberturaPublisher.(MavenCoberturaPublisher.java:237)
>   at sun.misc.Unsafe.ensureClassInitialized(Native Method)
>   at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
>   at 
> sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
>   at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
>   at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
>   at java.lang.reflect.Field.getLong(Field.java:528)
>   at 
> java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1586)
>   at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52)
>   at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:408)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.io.ObjectStreamClass.(ObjectStreamClass.java:400)
>   at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:297)
>   at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:531)
>   at 
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
>   at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
>

[JIRA] (JENKINS-13807) Email-ext Plugin Does Not work

[s.sog...@gmail.com (JIRA)]

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

sogabe resolved JENKINS-13807.
--

Resolution: Duplicate

> Email-ext Plugin Does Not work 
> ---
>
> Key: JENKINS-13807
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13807
> Project: Jenkins
>  Issue Type: Bug
>  Components: email-ext
>Affects Versions: current
> Environment: CentOS 6.2, Sun JDK 6.0.31, Jenkins ver. 1.464 installed 
> from yum repo
>Reporter: Jared Griffith
>  Labels: plugin
>
> I have installed and tried to activate the email-ext plugin, but when I try 
> to enable the extension for a particular job, it does not work.  I am getting 
> the following error with the Firefox Javascript debugger:
> Timestamp: 05/16/2012 06:16:42 PM
> Error: emailExtInit is not defined
> Source File: 
> http://jenkins.picsauditing.com/static/5f664cc9/scripts/hudson-behavior.js
> Line: 480
> Please help.
> The latest version of the plug in is installed and was installed from the 
> Jenkins Plugin UI.

--
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-13819) email notification can not send out whether the build is success or failed

[chenjingjing...@163.com (JIRA)]

pangpang wanzi created JENKINS-13819:


 Summary: email notification can not send out whether the build is 
success  or failed
 Key: JENKINS-13819
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13819
 Project: Jenkins
  Issue Type: Bug
  Components: email-ext
 Environment: Jenkins version:1.428
Reporter: pangpang wanzi


Email can not send out, error info as follows:
Email was triggered for: Success
Sending email for trigger: Success
ERROR: Could not send email as a part of the post-build publishers.
java.lang.NullPointerException

or

Email was triggered for: Success
Sending email for trigger: Success
ERROR: Could not send email as a part of the post-build publishers.
java.lang.NullPointerException
at java.util.regex.Matcher.quoteReplacement(Matcher.java:598)
at 
hudson.plugins.emailext.plugins.ContentBuilder$Tokenizer.appendReplacement(ContentBuilder.java:195)
at 
hudson.plugins.emailext.plugins.ContentBuilder.replaceTokensWithContent(ContentBuilder.java:96)
at 
hudson.plugins.emailext.plugins.ContentBuilder.transformText(ContentBuilder.java:67)
at 
hudson.plugins.emailext.ExtendedEmailPublisher.setContent(ExtendedEmailPublisher.java:369)
at 
hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:274)
at 
hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:220)
at 
hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:212)
at 
hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:174)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at 
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:682)
at 
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:657)
at 
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:635)
at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171)
at hudson.model.Run.run(Run.java:1420)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:230)
Finished: SUCCESS




--
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-13820) please create possibility to automatically set order of execution of matrix subtasks based on previously tracked time

[rgrigor...@gmail.com (JIRA)]

Roman G created JENKINS-13820:
-

 Summary: please create possibility to automatically set order of 
execution of matrix subtasks based on previously tracked time
 Key: JENKINS-13820
 URL: https://issues.jenkins-ci.org/browse/JENKINS-13820
 Project: Jenkins
  Issue Type: New Feature
  Components: plugin
 Environment: distributed matrix setup
Reporter: Roman G
Assignee: Lucie Votypkova


It will be good to have possibility for automatically set order of execution of 
matrix subtasks based on tracked time(in execution history) - longer subtask 
must be executed earlier then shorter. I think, it could help to decrease 
execution time for full matrix task. 
F.e. I have 2 nodes  and 3 matrix configurations(1,2,3) and estimation time of 
execution based on history is 1h ,2h, 3h. I suggest to write plugin which set 
execution order: 3->2->1. In this case, full execution time will be 3h (node 1 
- task 3, node 2 - task1+task2). In any other order full execution time will be 
longer.

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