[JIRA] [core] (JENKINS-12231) RPM upgrade does not honor JENKINS_USER, and always resets files ownership to jenkins
Georg Sash commented on JENKINS-12231 RPM upgrade does not honor JENKINS_USER, and always resets files ownership to jenkins I guess excluding the "jobs" sub directory in the data location from the chown operation would solve this. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven2] (JENKINS-18403) Jenkins 1.518 causes Java 5 Maven builds to fail
Georg Sash commented on JENKINS-18403 Jenkins 1.518 causes Java 5 Maven builds to fail Guys, it is a constantly reoccurring issue that non-Java5 compatible class files get leaked into the Jenkins distribution. Is it so hard to add a test case that explicitly checks if Java5 support is still intact?? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [maven2] (JENKINS-18178) All Maven 2 builds fail with java.lang.NoSuchMethodError DigestUtils.md5Hex
Georg Sash created JENKINS-18178 All Maven 2 builds fail with java.lang.NoSuchMethodError DigestUtils.md5Hex Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: maven2 Created: 03/Jun/13 2:29 PM Description: All our Jenkins builds using Maven2 are failing after upgrade to 1.517. Reverting back to 1.516 solves the issue. Our Maven 3 based builds are not affected. INFO ERROR FATAL ERROR INFO INFO org/apache/commons/codec/digest/DigestUtils.md5Hex(Ljava/io/InputStream;)Ljava/lang/String; INFO INFO Trace java.lang.NoSuchMethodError: org/apache/commons/codec/digest/DigestUtils.md5Hex(Ljava/io/InputStream;)Ljava/lang/String; at hudson.Util.getDigestOf(Util.java:557) at hudson.maven.reporters.MavenArtifactArchiver.postBuild(MavenArtifactArchiver.java:101) at hudson.maven.Maven2Builder.postModule(Maven2Builder.java:129) at hudson.maven.MavenBuilder$Adapter.fireLeaveModule(MavenBuilder.java:354) at hudson.maven.MavenBuilder$Adapter.postBuild(MavenBuilder.java:308) at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:68) 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:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) 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:185) at hudson.maven.MavenBuilder.call(MavenBuilder.java:154) at hudson.maven.Maven2Builder.call(Maven2Builder.java:79) at hudson.maven.Maven2Builder.call(Maven2Builder.java:55) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314) at java.util.concurrent.FutureTask.run(FutureTask.java:149) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919) at java.lang.Thread.run(Thread.java:738) INFO INFO Total time: 8 seconds INFO Finished at: Mon Jun 03 15:26:42 CEST 2013 INFO Final Memory: 49M/125M INFO channel stopped Finished: FAILURE Environment: Linux, IBM JDK6 and Sun JDK6 Project: Jenkins Priority: Blocker Reporter: Georg Sash This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups
[JIRA] (JENKINS-16542) java.lang.ClassFormatError: Failed to load org.apache.commons.codec.binary.Base64OutputStream
Georg Sash created JENKINS-16542 java.lang.ClassFormatError: Failed to load org.apache.commons.codec.binary.Base64OutputStream Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 30/Jan/13 11:14 AM Description: Going from 1.499 to 1.500 results in the following exception when trying to build projects with JDK5. Switching back to 1.499 solves the issue. The job is running with this configuration: Executing Maven: -B -f /var/opt/data/jenkins/workspace/pro031/pom.xml --fail-at-end -V -e help:effective-settings help:active-profiles clean package Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Maven home: /opt/maven/bin-3.0.4 Java version: 1.5.0, vendor: IBM Corporation Java home: /opt/java/java-ibmsdk-x86_64_5.0_SR15/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux", version: "2.6.32-279.el6.x86_64", arch: "amd64", family: "unix" ... INFO INFO Building pro031 1.0.4-SNAPSHOT INFO mojoStarted org.apache.maven.plugins:maven-help-plugin:2.1.1(default-cli) java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:619) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) at hudson.maven.Maven3Builder.call(Maven3Builder.java:100) at hudson.maven.Maven3Builder.call(Maven3Builder.java:66) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:284) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:678) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:703) at java.lang.Thread.run(Thread.java:813) Caused by: java.lang.ClassFormatError: Failed to load org.apache.commons.codec.binary.Base64OutputStream at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:193) at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:144) at java.lang.ClassLoader.loadClass(ClassLoader.java:650) at java.lang.ClassLoader.loadClass(ClassLoader.java:616) at java.lang.J9VMInternals.verifyImpl(Native Method) at java.lang.J9VMInternals.verify(J9VMInternals.java:69) at java.lang.J9VMInternals.verify(J9VMInternals.java:67) at java.lang.J9VMInternals.initialize(J9VMInternals.java:131) at hudson.maven.util.ExecutionEventLogger.mojoStarted(ExecutionEventLogger.java:274) at hudson.maven.Maven3Builder$MavenExecutionListener.mojoStarted(Maven3Builder.java:396) at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:84) at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:42) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:203) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at
[JIRA] (JENKINS-12231) RPM upgrade does not honor JENKINS_USER, and always resets files ownership to jenkins
Georg Sash commented on JENKINS-12231 RPM upgrade does not honor JENKINS_USER, and always resets files ownership to jenkins I have the exact same problem. this is very annoying. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14529) BindException whhen using --daemon with JMX
Georg Sash created JENKINS-14529 BindException whhen using --daemon with JMX Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 23/Jul/12 1:19 PM Description: java -Dcom.sun.management.jmxremote.port= -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -jar jenkins.war --deamon results in Forking into background to run as a daemon. Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: ; nested exception is: java.net.BindException: Address already in use This means I cannot use VisualVM on a deamonized Jenkins instance. I encountered this problem when using the RPM installer to setup Jenkins and afterwards manually adding the -D options to JENKINS_JAVA_OPTIONS in /etc/sysconfig/jenkins. Project: Jenkins Priority: Major Reporter: Georg Sash This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14529) BindException when using --daemon with JMX
Georg Sash updated JENKINS-14529 BindException when using --daemon with JMX Change By: Georg Sash (23/Jul/12 1:20 PM) Summary: BindException whhen when using--daemonwithJMX This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
