Thnx, I have now done some testing on 1.7.0-SNAPSHOT. It seems that the Keychain support on Mac OSX (10.6.7) doesn't work anymore. With SvnKit 1.3.5 I am able to work against a local test repository. With 1.7.0-SNAPSHOT I get this error:
SVNException: org.tmatesoft.svn.core.SVNAuthenticationException -> svn: Authentication required for '<http://svn.api.no:80> SVN' org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication required for '<http://svn.api.no:80> SVN' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:47) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:41) at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:218) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:564) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:280) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:268) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1007) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:179) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getRevisionNumber(SVNBasicDelegate.java:480) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.getLocations(SVNBasicDelegate.java:833) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:527) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2716) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doInfo(SVNWCClient16.java:2627) at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2202) Any changes in the API that I should be aware of? Semyon Vadishev wrote: > > Hi, > >> 1. It would be nice if you've had a Maven repository with nightly builds. >> This would have made it much easier to test this. > Agree. We're currently migrating to gradle, as a build tool, and > Sonatype Nexus, as artifact repository, for all our projects. I think we > will set up the environment in a week or two, so we will publish nightly > builds as maven artifacts soon. We will release SVNKit 1.3.6 with GNOME > Keyring support and some other enhancements a bit later. > > Meanwhile you may try builds from our trunk which are already in Maven > repository — > http://maven.tmatesoft.com/index.html#nexus-search;quick~svnkit. They > are no stable yet, but they do support GNOME keyring. The description > from my first email of the thread is still valid for these builds. > > If you're going to test authentication cache only, it's much safer to > use remote operations — ls, info, etc. > >> 2. When do you expect 1.4.0 to be released? > Usually we roll out the major release in a month after Subversion > release. According to Subversion roadmap — > http://subversion.apache.org/roadmap.html, there is certain features > development still in progress. So we don't have schedule yet. > > The most important feature of svn 1.7 is a new working copy format with > central metadata storage. It's based on SQLite database engine and we've > already implemented basic support for this new storage. That means that > first builds with full support of working copy operations will appear in > reasonable time after Subversion release. > > At the same time there are also enhancement in FSFS backend and HTTP/DAV > repository access. Some of them are backward compatible with the former > versions. Probably we will roll out these particular improvements in > minor releases after the major one. > > Please notice that the next major version of SVNKit is 1.7.0. We decided > to have the major version number similar to Subversion one. > > Thank you for your feedback. > > Semen Vadishev, > TMate Software, > http://svnkit.com/ - Java [Sub]Versioning Library! > http://sqljet.com/ - Java SQLite Library! > > > > On 3 May 2011 14:45, lazee wrote: >> >> Semyon Vadishev wrote: >>> Hello everyone, >>> >>> Some time ago we've implemented experimental GNOME Keyring support for >>> SVNKit. Generally it allows to keep any sensitive data (passwords, >>> certificate passphrases, etc) in GNOME Keyring. >>> >>> We've already done some internal testing and now we decided to ask the >>> community to adopt the existing code for your needs and test it as well. >>> >>> You may find the latest version of SVNKit with GNOME Keyring support at >>> https://teamcity.svnkit.com/repository/download/bt22/13537:id/deploy/org.tmatesoft.svn_1.3.5.7544.standalone.zip >>> (login as guest if prompted). >>> >>> Please notice that the corresponding code uses native binaries, so JNA >>> library has to be on classpath in order to make things work. JNA library >>> is included to the distribution. >>> >>> By default SVNKit doesn't try to use GNOME Keyring. To enable this >>> feature you have to set 'svnkit.library.gnome-keyring.enabled' property >>> to 'true'. >>> >>> Let's consider the following use cases: >>> >>> >>> >>> I. You use svn or jsvn utilities. >>> >>> To test SVNKit-based command line utility, jsvn, please do the >>> following: >>> >>> 1) Ensure you won't corrupt existing authentication data: >>> >>> $ copy -r ~/.subversion/auth ~/.subversion/auth.backup >>> >>> 2) Ensure you have Keyring support enabled: >>> >>> $ export SVNKIT_OPTIONS="${SVNKIT_OPTIONS} >>> -Dsvnkit.library.gnome-keyring.enabled=true" >>> >>> 3) Ensure Subversion configuration allows SVNKit to use GNOME Keyring as >>> password storage: >>> >>> ~/.subversion/config file has "password-stores = gnome-keyring" line or >>> corresponding line is ignored. No option means using password storage >>> available for the operating system. >>> >>> 4) Run those commands you usually use. Ensure that jsvn behaves as >>> expected and doesn't ask you to store passwords in plain text. >>> >>> $ jsvn ls $repo >>> >>> $ jsvn checkout $repo $wc >>> >>> $ jsvn commit $wc >>> >>> 5) Try to use jsvn in non-interactive mode: >>> >>> $ jsvn ls --non-interactive $repo >>> >>> $ jsvn checkout --non-interactive $repo $wc >>> >>> $ jsvn commit --non-interactive $wc >>> >>> In this mode jsvn must skip prompting you for any details. In case >>> credentials were requested by the repository and they are not yet >>> cached, jsvn has to exit with error. >>> >>> >>> >>> II. You integrate SVNKit into client-side application. >>> >>> You might already noticed some changes in classes related to >>> authentication, resp. DefaultSVNAuthenticationManager, >>> ISVNAuthenticationStorageOptions, ISVNHostOptionsProvider, etc. They are >>> not public API, but could be used in certain cases. We made these >>> changes in order to support OS X Keychain and now Keyring-related code >>> breaks the binary compatibility for this classes, too. >>> >>> If you're user of DefaultSVNAuthenticationManager interface there are >>> three places to look into: >>> >>> 1) ISVNAuthenticationStorageOptions interface. Its basic usage looks >>> like follows: >>> >>> ISVNAuthenticationStorageOptions authStorageOpts = new >>> ISVNAuthenticationStorageOptions() { >>> >>> // Enable or disable non-interactive mode >>> public boolean isNonInteractive() throws SVNException { >>> return false; >>> } >>> >>> // In interactive mode prompts user for credentials >>> public ISVNAuthStoreHandler getAuthStoreHandler() throws >>> SVNException >>> { >>> return null; >>> } >>> >>> public boolean isSSLPassphrasePromptSupported() { >>> return false; >>> } >>> >>> // In interactive mode asks user for the name of keyring to use >>> public ISVNGnomeKeyringPasswordProvider >>> getGnomeKeyringPasswordProvider() { >>> return null; >>> } >>> }; >>> >>> DefaultSVNAuthenticationManager manager = >>> (DefaultSVNAuthenticationManager) >>> SVNWCUtil.createDefaultAuthenticationManager(); >>> manager.setAuthenticationStorageOptions(authStorageOpts); >>> >>> As you can see there is an analogy between #isNonInteractive() method >>> and 'non-interactive' command line option. >>> >>> 2) ISVNHostOptionsProvider and ISVNHostOptions interfaces. >>> >>> One could find analogy between ~/.subversion/servers configuration file >>> and ISVNHostOptions class. The last one is API for the corresponding >>> configuration options. E.g. in order to disable any authentication >>> storage, provide necessary implementation of >>> ISVNHostOptions#isAuthStorageEnabled() and make authentication manager >>> use this implementation. >>> >>> 3) DefaultSVNOptions class. >>> >>> Finally, if you want to mimic ~/.subversion/config configuration options >>> provide necessary instance of DefaultSVNOptions class. E.g. you can >>> restrict usage of certain password storage types via corresponding >>> implementation of DefaultSVNOptions#getPasswordStorageTypes(). >>> >>> >>> >>> III. You integrate SVNKit into server-side application. >>> >>> All the information above is also relevant for server-side integration, >>> but be carefully when switching to the new version of SVNKit. Since OS X >>> Keychain and GNOME Keyring support is enabled, always enable >>> non-interactive mode for DefaultSVNAuthenticationManager. Otherwise your >>> code most likely will get stuck during password storage access. See >>> ISVNAuthenticationStorageOptions#isNonInteractive(). >>> >>> >>> >>> Considering these use cases, please keep in mind a known issue related >>> to Keyring: >>> >>> If Keyring daemon is not running, Subversion client initializes it via >>> DBus mechanism once needed. SVNKit is not able to do that. So >>> application users have to be sure, that keyring daemon is properly >>> loaded and initialized to work with. >>> >>> Thanks in advance! >>> >>> -- >>> Semen Vadishev, >>> TMate Software, >>> http://svnkit.com/ - Java [Sub]Versioning Library! >>> http://sqljet.com/ - Java SQLite Library! >>> >>> >>> >>> >> 1. It would be nice if you've had a Maven repository with nightly builds. >> This would have made it much easier to test this. >> >> 2. When do you expect 1.4.0 to be released? > > > > -- View this message in context: http://old.nabble.com/GNOME-Keyring-support-tp31183957p31532936.html Sent from the SVNKit - Users mailing list archive at Nabble.com.
