http://maven.tmatesoft.com/content/groups/public seems to be password
protected
Sorry, try this one —
http://maven.tmatesoft.com/content/repositories/snapshots/
Semen Vadishev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!
On May 30, 2011 13:54 , lazee wrote:
Hi Semen,
http://maven.tmatesoft.com/content/groups/public seems to be password
protected, which makes it hard to add it as a Maven repository in my
pom.xml.
/Jakob
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?
