|
||||||||
|
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
@Daniel Beck I have to disagree that the workaround stated is easy to implement. The servers running Jenkins nodes are not under my control. Due to firm policy, only the OS supported version may be installed. With servers running multiple operating systems, the subversion versions are varied.
There is a less obvious workaround. Configure each application that Jenkins calls, such as Maven, a shell script or command-line svn, to use an jar version of subversion that matches the version Jenkins is using.
In Maven I have configured a plugin like this:
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.2.2</version>
<configuration>
<tagBase>${svn.base}/tags</tagBase>
<providerImplementations>
<svn>javasvn</svn>
</providerImplementations>
</configuration>
<dependencies>
<dependency>
<groupId>com.google.code.maven-scm-provider-svnjava</groupId>
<artifactId>maven-scm-provider-svnjava</artifactId>
<version>2.1.1</version>
<scope>compile</scope>
</dependency>
</dependencies>
</plugin>