I have tested 'jsvn' utility from 1.7.0 build on my OS X 10.5.8 and it worked just fine.
There are certain differences between 1.3.5 and 'maven' branch (maven artifacts built from this branch, which is approximately trunk), but there are no API changes. I'm afraid the problem is somehow related to maven dependencies — SVNKit fails to access OS X Keychain with no JNA binaries at runtime. Could you check that JNA library is in classpath when you running the code. Debug log would be helpful here. Find the description how to get it here — https://wiki.svnkit.com/Troubleshooting. There are also internal changes, especially those related to HTTP authentication mechanisms. If that possible, could you please test authentication against some svnserve daemon, i.e. using svn:// protocol, not http://. If all above is not relevant for your particular case, let's see what could be wrong with the code. So, you have login and password stored in the keychain, right? Please ensure you do — find "<http://svn.api.no:80> SVN" item and check that access to the item is granted for Java applications. Otherwise it's not clear for me how do you provide the credentials for the corresponding realm. As I can see, you use the authentication manager which by default don't have any callback to provide necessary credentials, that means this authentication manager uses cached version of credentials. That means 1.3.5 build can read this cached data, but 1.7.0 version is not able to do that, thus we have a bug. Not to bother you with such non-stable builds, you might want to wait until we merge gradle/maven changes back to trunk and 1.3.x branches. So you can try pure trunk version or pre-release 1.3.6 build soon. Also you may try old-school jar-based way. You can download necessary jars from our build server — 1.3.x https://teamcity.svnkit.com/repository/download/bt22/14050:id/deploy/org.tmatesoft.svn_1.3.5.7590.standalone.zip and trunk https://teamcity.svnkit.com/repository/download/bt3/14080:id/deploy/org.tmatesoft.svn_1.4.0.7613.standalone.zip. Log in as a guest if prompted. Thank you. Semen Vadishev, TMate Software, http://svnkit.com/ - Java [Sub]Versioning Library! http://sqljet.com/ - Java SQLite Library! On 3 May 2011 20:27, lazee wrote: > This is the way I initialize the client: > > clientManager = SVNClientManager.newInstance(); > SVNRepositoryFactoryImpl.setup(); > if (log.isDebugEnabled()) { > SvnDebugLogger.initSvnDebugLogger(); > } > DAVRepositoryFactory.setup(); > FSRepositoryFactory.setup(); > > > > lazee wrote: >> 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? >>> >>> >>> >>
