svn: missing argument: –password

I am currently setting up the Maven Release Plugin for a project which is stored in a SVN repository. The plugin needs to do modifications in the repository, for which it executes a svn command. The credentials it gets from ~/.m2/settings.xml, and the password is passed with the --password parameter. On the command line the password is masked.

Now I ran into the trouble that the svn command fails to execute with the message

svn: missing argument: --password

The complete output is:

[INFO] Executing: /bin/sh -c cd /Users/thoms/Development/projects/fornax/ws/fornax-parent && svn --username kthoms --password '*****' --no-auth-cache --non-interactive status
[INFO] Working directory: /Users/thoms/Development/projects/fornax/ws/fornax-parent
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.031s
[INFO] Finished at: Wed Nov 26 09:39:38 CET 2014
[INFO] Final Memory: 10M/24M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on project fornax-parent: Unable to check for local modifications
[ERROR] Provider message:
[ERROR] The svn command failed.
[ERROR] Command output:
[ERROR] svn: missing argument: --password
[ERROR] Geben Sie »svn help« für weitere Hilfe ein.

I could not explain this, since obviously a svn command was executed with passing my password. So I copied only the svn command and executed this only from command line:

svn --username kthoms --password MYPLAINPASSWORD --no-auth-cache --non-interactive update

Same effect.

Finally I found out that the password itself was causing the problem. Without telling too much I can say it started with the ‘#’ character. This lead to the fact that on shell this was interpreted as a comment. At the end this is completely logical, but I did not think about that scenario when choosing the password. And the error message was a bit misleading here.

Xtext, Maven and Source Control

Although I more and more use Git for source control, I face Subversion still frequently in daily life. I follow the rule that I don’t want to check in what can be generated in a headless build, where I usually use Maven. Xtext projects have the source folders src-gen and xtend-gen, where generated sources go to. Further, you will usually have 3 projects: The grammar project, the UI project and a test project.

In this article I will show some guidelines that I follow when checking in Xtext projects into source control.

Handling the src-gen folder

The content of src-gen can be produced during a build, so I do not check in the content of it. What needs to be considered is that is no good idea to ignore the folder completely, since it would be missing when fresh checking out the project. This leads to an incomplete build path, and the MWE2 workflow is not executable from Eclipse until the folder was created. This is because the .mwe2 file needs to be on the project’s classpath, which is not the folder src, but the output folder, bin or target/classes. It will be copied automatically with default workspace settings only when the build path is complete. This behavior can be changed in the workspace / project settings in Java / Compiler / Building.

If you rate down build path problems to warning level or just disable build abortion on errors, the .mwe2 file will be copied anyway to the target folder. If using project specific settings you could even check in these settings and share it in the team.

I prefer to check in the src-gen folder, but avoid that any content gets checked in. To do so, add the folder with svn add, but none of its content! Best you do this immediately after the Xtext project was created. After the folder was scheduled for adding, you can set the svn:ignore property to value “*”.

The xtend-gen folder

At the moment it is not possible to compile .xtend files during a Maven build, so the content of xtend-gen must be checked in and handled like handcrafted sources. To cut this story short: Xtend and Java files depend usually on each other. Xtend files cannot be compiled until Java sources from the same project were compiled, and some Java sources will depend on about-to-be-compiled Xtend sources. So the Java source compilation fails, aborting the build.

I hope to solve this problem soon.

Some ignore patterns

On the root of each of the 3 Xtext projects, set the property svn:ignore to this value:


Configure Maven clean plugin

When running mvn clean on your project you would like to to clean up all derived resources. The target folder will be removed by default, but this is not enough. The content of the src-gen folders must be cleaned up as well. This can be done by configuring the maven-clean-plugin. One thing to consider is that Xtext has 3 projects. It is not correct to configure the clean plugin for all 3 projects due the lifecycle of a Maven build: The projects will be build after each other, executing all lifecycles per project. If you execute a “mvn clean install” this would have the effect that

  1. clean is called on the grammar project
  2. in phase generate-sources the Xtext implementation classes are produced to all 3 projects
  3. the sources for the grammar project are compiled
  4. now the build continues with the next module, e.g. the UI project
  5. the project will be cleaned, removing the previously generated sources
  6. compilation fails, since the generated sources are missing now

For this reason the clean plugin must be configured only in the grammar project, and it should clean up the sources from all 3 projects. Now comes again a detail related to source control: Since we want to have the src-gen checked in, we have to avoid that the SCM related folders and files are removed. Otherwise this would confuse your SCM system. So these files must be excluded from deletion. This leads to the following configuration:


Set svn:ignore for multiple files from command line

I just faced faced the problem that I wnated to use the “svn setprop” command on the command line to ignore multiple elements. You could create a file which contains a newline seperated list of files to ignore and pass this file with -F.

svn propset svn:ignore -F ignorelist.txt .

But this requires an additional file. I found the solution in the comments of this article: You could just open quotes and then enter newlines on the command line itself, until the quotes are closed. This means you can use it like this:

svn propset svn:ignore “first
 third” .

Fixing subversion problem “Error validating server certificate”

I have faced the annoying problem that for unknown reasons I got a security exception when accessing the subversion repository for one of my Google Code projects. This used to work before, but maybe the server has been changed. However, if the certificate is not trusted subversion will ask you whether you trust the certificate and if you want to add this certifacte.

svn info
Error validating server certificate for '':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: *
 - Valid: from Wed, 16 Feb 2011 00:27:28 GMT until Thu, 16 Feb 2012 00:37:28 GMT
 - Issuer: Google Inc, US
 - Fingerprint: 34:4b:90:e7:e3:36:81:0d:52:1f:10:c0:4c:98:66:90:4a:9e:05:c9
(R)eject, accept (t)emporarily or accept (p)ermanently?

The problem now is that even if I entered the “p” option the next time I access SVN the same exception occurs again.

My issue was solved now by cleaning the directory “~/.subversion/auth/svn.ssl.server”.

 rm ~/.subversion/auth/svn.ssl.server/*

Upgrading OSX subversion client

Running SVN from my command line for a project I originally checked out with Eclipse gave me the message

“svn: This client is too old to work with working copy ‘.’; please get a newer Subversion client”

My subversion version was 1.4.4:
> svn --version
svn, version 1.4.4 (r25188)
compiled Jun 23 2007, 08:53:30
So I downloaded the “Universal Subversion 1.6.3 Binaries for MAC OS X (32 and 64 bit)” package from CollabNet.
By default this package installs subversion to /opt/subversion. So still my old subversion installation was 1.4.4
> which svn
I edited then ~/.profile and set /opt/subversion/bin in front of my PATH:
export PATH=/opt/subversion/bin:/usr/local/bin:/opt/local/bin:/opt/local/sbin:$PATH
And finally subversion now is used in the right version:
>svn --version
svn, version 1.6.3 (r38063)
compiled Jun 23 2009, 16:38:16

Posted via email from Karsten’s Blog