Nice! I sure will try it right now!
Semyon Vadishev wrote: > > Hello Jakob, > > 1.3.x snapshots are already available in our maven repository. Can you > please test this version of SVNKit? > > Thanks in advance. > > Semen Vadishev, > TMate Software, > http://svnkit.com/ - Java [Sub]Versioning Library! > http://sqljet.com/ - Java SQLite Library! > > > On May 8, 2011 20:34 , lazee wrote: >> 1. According to the test found in SVNJNAUtil.isJNAPresent() JNA is >> present in >> my build. >> >> 2. I have controlled that my login and password are in my keychain (After >> all it works >> fine with the 1.3.5 build). >> >> 3. I have created a test-app that can be downloaded here: >> www.jakobnielsen.net/etc/svnkit-test.zip >> >> The output from the app when running on 1.3.5 (Works fine): >> >> 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! >> 53 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: Keep-Alive >> timeout >> detected >> 323 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 706 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 907 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 1217 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 1352 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 1831 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 1860 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 2030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 2343 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 2344 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 2511 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 2854 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 2855 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 3029 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 3030 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 3469 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 3471 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 3618 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 3981 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 3983 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 4089 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 4492 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 4493 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 4498 [Tester.main()] DEBUG InfoHandler - HandleInfo: >> org.tmatesoft.svn.core.wc.SVNInfo@4d12ee4f >> 4498 [Tester.main()] DEBUG InfoHandler - Setting repository info >> 4499 [Tester.main()] DEBUG Tester - Got info. Basedir : >> /people/jakob/test >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] BUILD SUCCESSFUL >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Total time: 11 seconds >> [INFO] Finished at: Sun May 08 18:26:50 CEST 2011 >> [INFO] Final Memory: 17M/265M >> [INFO] >> ------------------------------------------------------------------------ >> >> >> The output from the app when running on the 1.7.0-SNAPSHOT (Doesn't >> work): >> >> 0 [Tester.main()] INFO Tester - JNA is present according to SVNKIT! >> 23 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >> working copy format >> 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >> working copy format >> 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >> working copy format >> 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >> working copy format >> 24 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >> working copy format >> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >> working copy format >> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >> working copy format >> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >> working copy format >> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >> working copy format >> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >> working copy format >> 25 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >> working copy format >> 27 [Tester.main()] DEBUG SvnDebugLogger - CLI :FINE: svn: Unsupported >> working copy format >> 265 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >> stream requested... >> 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >> stream requested... >> 266 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 266 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >> stream requested... >> 404 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >> stream requested... >> 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >> stream requested... >> 816 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :SENT >> 816 [Tester.main()] DEBUG SvnDebugLogger - DEFAULT :FINE: socket output >> stream requested... >> 992 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :READ >> 993 [Tester.main()] DEBUG SvnDebugLogger - NETWORK :FINE: svn: >> Authentication required for '<http://svn.something.no:80> SVN' >> 995 [Tester.main()] DEBUG Tester - SVNException: >> org.tmatesoft.svn.core.SVNAuthenticationException -> svn: Authentication >> required for '<http://svn.something.no:80> SVN' >> org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication >> required for '<http://svn.something.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:565) >> 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) >> at Tester.getRepositoryInfo(Tester.java:45) >> at Tester.run(Tester.java:39) >> at Tester.main(Tester.java:57) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:291) >> at java.lang.Thread.run(Thread.java:680) >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] BUILD SUCCESSFUL >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Total time: 6 seconds >> [INFO] Finished at: Sun May 08 18:14:31 CEST 2011 >> [INFO] Final Memory: 17M/265M >> [INFO] >> ------------------------------------------------------------------------ >> >> >> >> I do not like the "Unsupported working copy format" at all? I will set up >> a >> svn:/-test soon if this doesn't give you enough answers. >> >> I might also create a Maven build file so that I can test against a trunk >> build. >> >> >> Best regards >> >> Jakob Vad Nielsen >> >> >> Semyon Vadishev wrote: >>> 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? >>>>>> >>>>>> >>> >>> >>> > > > -- View this message in context: http://old.nabble.com/GNOME-Keyring-support-tp31183957p31731508.html Sent from the SVNKit - Users mailing list archive at Nabble.com.
