did you try to configure your scm url using | separator ?

http://maven.apache.org/scm/scm-url-format.html

In the scenario being used, no password info is in the scm url. The password was provided when authenticating to download the POM from subversion.

This is also true when specifying SCM username/pass in the release plugin functionality. The general problem is that commands are run using a command shell. Username and password are concatenated into these commands without protecting the command interpreter from special characters, if present. This is a security vulnerability as well. Because my password is inserted directly into a shell command, I can use a specially crafted username or password to do some really nasty things.

Unfortunately, because continuum uses the shell, any solution will raise portability concerns. For instance, if we assume bash we can use the special $'' quoting feature:

svn --username $'it\'s cool' --password $'but don\'t try this in tcsh or in window\'s'

However, this is not portable across all target platforms.

Perhaps it would be possible to detect the shell that the continuum is running in by executing carefully crafted commands on startup. Once the shell is detected, the proper procedure could be chosen for escaping. For instance, if there is support for bash's quoting style, use it in combination with escaping single quotes in passwords with a backslash. If using windows, use an appropriate scheme, tcsh another, etc.

Another alternative is to allow continuum administrators to configure the shell as part of setup. Yet another would be don't bake in the commands at all, allow the administrators to edit configuration files with the commands.

At the very least, I think securing it is a wise choice. The easiest short term fix would probably be to use double quotes and escape double quotes present in the values with a backslash. This would clear up the security issue, and would support most special characters which would be significantly better than the current solution. The only big problem would be parameter expansion in values that contained $ (or double-% on windows). You could approach this with one of the techniques above, or you could simply detect problem values and give the user feedback that their password is not supported.

duplicates CONTINUUM-1360.
Can you try with trunk and reopen it if it's not fixed ?

This seems to remedy the case issued on the ticket (leading paren), and it works for my case as well (contains single quote). Closed it is.