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?
