-
Bug
-
Resolution: Unresolved
-
Major
-
None
Hi.
We get the following error running tests on Jenkins.
Xvfb starting$ Xvfb :1 -screen 0 1152x900x8 -fbdir /home/tomcat/.hudson/2012-11-16_11-25-053509576821944113109xvfb Parsing POMs Xvfb stopping FATAL: tried to access method hudson.model.AbstractBuild.setBuiltOnStr(Ljava/lang/String;)V from class hudson.maven.MavenModuleSetBuild$RunnerImpl java.lang.IllegalAccessError: tried to access method hudson.model.AbstractBuild.setBuiltOnStr(Ljava/lang/String;)V from class hudson.maven.MavenModuleSetBuild$RunnerImpl at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:646) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586) at hudson.model.Run.execute(Run.java:1516) at hudson.model.Run.run(Run.java:1462) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:487) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236)
Here is our set-up.
Jenkins version: 1.490
The Jenkins.war was renamed to Hudson.war and overwrote the Hudson.war one we had within tomcat. That allowed is to retain all the jobs we have now, including the ones that we build with maven but have no screens/windows.
We also have XVFB installed on the master, which is a RHL 4 box (Nahant).
And we use the latest XVFB plugin, VERSION 1.0.6 (NoV 05, 2012, required core dependencies = 1.398)
The tests are Webdriver Java tests. Maven is used for building. The Pom gives no issues when we run tests locally. Below is what we have in the Pom, very few dependencies.
<modelVersion>4.0.0</modelVersion> <groupId>ourGroupId</groupId> <artifactId>ourArtifactId</artifactId> <version>1</version> <packaging>jar</packaging> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.5.1</version> <configuration> <source>1.7</source> <target>1.7</target> </configuration> </plugin> <plugin> <artifactId>maven-failsafe-plugin</artifactId> <version>2.12.3</version> <executions> <execution> <goals> <goal>integration-test</goal> <goal>verify</goal> </goals> </execution> </executions> <configuration> <forkMode>pertest</forkMode> <printSummary>true</printSummary> </configuration> </plugin> </plugins> </build> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.10</version> <type>jar</type> <scope>compile</scope> </dependency> <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-java</artifactId> <version>2.25.0</version> </dependency> <dependency> <groupId>org.easytesting</groupId> <artifactId>fest-assert</artifactId> <version>1.4</version> <scope>test</scope> </dependency> <dependency> <groupId>com.intellij</groupId> <artifactId>annotations</artifactId> <version>9.0.4</version> </dependency> <dependency> <groupId>joda-time</groupId> <artifactId>joda-time</artifactId> <version>2.1</version> </dependency> <!-- required for selenium grid --> <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-server</artifactId> <version>2.25.0</version> <type>jar</type> <scope>compile</scope> </dependency> <dependency> <groupId>org.seleniumhq.selenium</groupId> <artifactId>selenium-remote-driver</artifactId> <version>2.25.0</version> <type>jar</type> <scope>compile</scope> </dependency> </dependencies> </project>
I am running Maven 3.0.4, and that's what I have in the path.
Please help.
Jan
This is what I saw whilst trying to understand the error and look for a workaround/fix...
setBuiltOnStr
protected void setBuiltOnStr(String builtOn)
Allows subtypes to set the value of builtOn. This is used for those implementations where an AbstractBuild is made 'built' without actually running its run() method.
Since:
1.429
I do understand that AbstractBuild is the base implementation of Run, but then I don't quite get why this is just being made "built" without running the run method. That seems to be the issue here, and I have no way to bypass this when running on Jenkins. Would a pure jenkins installation handle this better than a one-time Hudson installation that was updated?