Hi Sebastian,
this is first of all more an svn commandline issue rather than a Maven /
maven-release-plugin issue.
For that reason you should start by calling svn directly from the
commandline. In the end, that's exactly what maven-release-plugin
(actually the scm-svn-provider) does. Once it can be called from
commandline, it should be a simple step to make it work with Maven.
"svn status" or "svn up" are easy to verify, but don't always require
credentials (depends how the access is controlled by the svn server)
"svn commit" does require authentication.
How credentials are stored: that's all up the the svn client.
thanks,
Robert
Op Fri, 27 Mar 2015 10:35:51 +0100 schreef Sebastian Oerding
<[email protected]>:
Hi Robert,
- I have looked at the Maven SCM project but do not get my problem
solved or more hints on it
- The maven-release-plugin is locked (with version 2.5, not 2.5.1)
- If running maven with -X according to console no credentials are
provided when accessing the SVN
- If running maven with -Dusername / -Dpassword the credentials are
shown (password masked) and it works, however changing the password at
least monthly for each run configuration / bat file / ... is no real
solution
- My colleagues encounter the same problem having switched to SVN 1.8
- How can I get a JIRA account to report a bug?
- I know that SVN really changes from 1.6 to 1.8, maybe this problem
stems from there?
- I read that the order of authentication mechanism changes, however
trying parameter -Dsvnkit.http.methods=Basic,Digest,Negotiate,NTLM did
not help
- Does the maven-scm-plugin should be able to access SVN with Windows 7
+ Active Directory by using the system's Kerberos / NTLM ticket or was
there any desupport of this feature?
- I also had the problem after the last password change but somehow
managed it by doing a single commit with Tortoise, saving the
credentials (deleting %USER%\AppData\Roaming\Subversion\auth before).
Afterwards the maven-release worked as expected. Unfortunately this
approach seems to work no more. Hence how can I check where are the
credentials taken from? Is there some additional kind of extreme logging
besides -e / -X switches?
Thanks in advance,
Sebastian
-----Ursprüngliche Nachricht-----
Von: Robert Scholte [mailto:[email protected]]
Gesendet: Freitag, 27. März 2015 08:51
An: Maven Users List
Betreff: Re: maven-release-plugin / SVN credentials
Hi Sebastian,
since your issue has to do with svn, one needs to look at the Maven SCM
project.[1] That's what the maven-release-plugin is using to the
commits, tags and checkouts.
First ensure you've locked the version of the maven-release-plugin,
preferably the lastest (i.e. 2.5.1).
If you run the plugin with logging level set to debug (by adding the -X
argument) you'll see the commandline
which is executed. You should be able to do the same (do strip off the
cmdshell specific part). That should give you the same exception and
might give you a hint how this could be fixed.
Verify if it is a knows issue in Jira[2], sometimes such issues give
extra info.
Verify the SCM Subversion page[3], it also describes some additional
configuration.
If this can't be solved by commandline, then there's a svnjava
implementation which you could use[4].
thanks,
Robert
[1] http://maven.apache.org/scm/maven-scm-providers/index.html
[2] http://jira.codehaus.org/browse/SCM/component/11191
[3] http://maven.apache.org/scm/subversion.html
[4]
https://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/wiki/Usage
Op Thu, 26 Mar 2015 08:20:31 +0100 schreef Sebastian Oerding
<[email protected]>:
Hello,
I have a problem with the maven-release-plugin using the SVN
credentials (details below). I always get an SVN authorization error.
It seems that the release plugin does not use the existing
credentials. Unfortunately I'm even not sure whether it is a problem
of the maven-release-plugin or SVN. How can I check / get a log which
credentials / whether credentials are actually used?
Please explain me how an installed SVN is used (SlikSvn and Tortoise
SVN installed, both with version 1.8 of the subversion protocol).
Details:
I'm in a company where we have Windows 7, 64 bit systems and an Active
Directory for Single Sign On (This Windows Kerberos / NTLM like stuff).
The maven-release-plugin worked fine until switching from subversion
1.6 to subversion 1.8. However I had exactly the same problem last
month after the monthly password change. Surprisingly I was able to
get this solved by making a single commit with Tortoise SVN providing
the credentials (and choosing Tortoise to save them). However after my
laptop has been renewed the same problem occurs again and I can not
solve it using the same trick as before.
Using Google I found a lot of posts on stackoverflow and similar stuff
where users report a problem with the maven-release-plugin and SVN
credentials. However all of the solutions presented are unacceptable
to me or do not solve my problem. For example I can not store my
company wide password in some file which is checked into the SVN.
Providing the parameters for each invocation of the
maven-release-plugin adjusting them every month would also be somehow
risky. At least it would be error-prone - every time when I forget to
adjust the password after a monthly change I have to rollback the
release, clean up the project, adjust the settings and try again.
In my previous setup where I was able to solve the problem by a
Tortoise commit I noticed that the SVN credentials persisted under
%USER%\AppData\Roaming\Subversion\auth changed. Before there were only
empty directories, now there is a directory svn.simple which contains
a text file with the SVN realm, username and so on as expected. The
password also seems to be fine but I can not definitely say as it is
encrypted.
Do you have any further hints on that, maybe a SVN mailing list where
to go?
With kind regards,
Sebastian Oerding
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
