Closed GoogleCodeExporter closed 9 years ago
IvySvn is built against SvnKit 1.3.4. What if you use that version instead of
the newer one you mentioned above?
Original comment by massdosage
on 15 Mar 2012 at 10:16
Trying it now. However, the download includes the SVNKIT version mentioned?
Original comment by ggb...@yahoo.com
on 15 Mar 2012 at 1:18
Same error. I reversed compiled the svnkit class SVNRepository and the method
getFile is in there. Any other ideas that could be causing this. As is this
tool is the exact solution that we need if I can get the retrieve working.
Original comment by ggb...@yahoo.com
on 15 Mar 2012 at 1:41
The decompile code is:
public abstract long getFile(String paramString, long paramLong, SVNProperties paramSVNProperties, OutputStream paramOutputStream)
throws SVNException;
I notice that the parameter list is expecting a long as the second parameter.
The actual call is passing 3 strings as follows:
org.tmatesoft.svn.core.io.SVNRepository.getFile(Ljava/lang/String;JLorg/tmatesoft/svn/core/SVNProperties;Ljava/io/OutputStream;)J
Original comment by ggb...@yahoo.com
on 15 Mar 2012 at 1:48
full exception:
[ivy:retrieve] found BankCard#TeliumGeneric;USA-V0225 in
ivysvn-bin-gnuarmrelease-retrieve-resolver
[ivy:retrieve] downloading
http://narsvn/repo/Bin/ivy/repository/BankCard/Apps/TeliumGeneric/USA-V0225/GNU_
ARM_RELEASE/8295290225.AGN ...
BUILD FAILED
E:\sSCM\ivy_targetsxxx.xml:65: java.lang.NoSuchMethodError:
org.tmatesoft.svn.core.io.SVNRepository.getFile(Ljava/lang/String;JLorg/tmatesof
t/svn/core/SVNProperties;Ljava/io/OutputStream;)J
at fm.last.ivy.plugins.svnresolver.SvnDao.getFile(SvnDao.java:230)
at fm.last.ivy.plugins.svnresolver.SvnRepository.get(SvnRepository.java:326)
at org.apache.ivy.plugins.resolver.RepositoryResolver.get(RepositoryResolver.java:194)
at org.apache.ivy.plugins.resolver.BasicResolver.getAndCheck(BasicResolver.java:875)
at org.apache.ivy.plugins.resolver.BasicResolver$6.download(BasicResolver.java:1041)
at org.apache.ivy.core.cache.DefaultRepositoryCacheManager.download(DefaultRepositoryCacheManager.java:827)
at org.apache.ivy.plugins.resolver.BasicResolver.download(BasicResolver.java:726)
at org.apache.ivy.plugins.resolver.RepositoryResolver.download(RepositoryResolver.java:282)
at org.apache.ivy.core.resolve.ResolveEngine.downloadArtifacts(ResolveEngine.java:373)
at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:316)
at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:195)
at org.apache.ivy.Ivy.resolve(Ivy.java:502)
at org.apache.ivy.ant.IvyResolve.doExecute(IvyResolve.java:244)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
at org.apache.ivy.ant.IvyPostResolveTask.ensureResolved(IvyPostResolveTask.java:217)
at org.apache.ivy.ant.IvyPostResolveTask.prepareAndCheck(IvyPostResolveTask.java:164)
at org.apache.ivy.ant.IvyRetrieve.doExecute(IvyRetrieve.java:57)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
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.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:809)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
Total time: 1 second
Original comment by ggb...@yahoo.com
on 15 Mar 2012 at 2:26
Aah, OK, you said in the original report that the version of SvnKit was
1.4.2_17-b06. I assume you got that from the manifest files inside svnkit.jar
which actually isn't the version number of SvnKit. The version number is found
inside the root of the jar file in a file called "svnkit.build.properties".
That should be 1.3.4 - can you confirm?
Is there any way you could have any other version of SvnKit on your classpath?
If I look at the code that IvySvn calls on SvnKit from the above trace it's the
following abstract method on org.tmatesoft.svn.core.io.SVNRepository:
public abstract long getFile(String s, long l, SVNProperties svnproperties, OutputStream outputstream) throws SVNException;
The code in fm.last.ivy.plugins.svnresolver.SvnDao on line 230 is so:
readRepository.getFile("", revision, null, output);
where
readRepository is of type org.tmatesoft.svn.core.io.SVNRepository
the first param is obviously a string ("")
revision is handed in to the method as a primitive long (long revision),
the third parameter is null so should be fine to pass in for any Object type,
and output is BufferedOutputStream output output = new BufferedOutputStream(new
FileOutputStream(destination)) where BufferedOutputStream extends OutputStream.
So that should match the getFile method signature. What made you think three
strings were being passed in?
The only thing I can think of going wrong here is some classpath and version
mismatch error between Ivy, IvySvn and SvnKit.
Original comment by massdosage
on 15 Mar 2012 at 3:23
you nailed it. I had a version of javasvn.jar in the classpath. javasvn must be
some deprecated instance of svnkit? I removed it from the classpath and voila
all is working well. Thank you so much for your help. Is there somewhere ivysvn
can be financially supported. I would like to see this tool continually
supported.
Original comment by ggb...@yahoo.com
on 15 Mar 2012 at 3:42
Excellent, I'm glad to hear that fixed it, I'm not sure what javasvn is but
there are quite a few tools out there which use svnkit under the hood so having
conflicting versions is always a distinct possibility.
As for financial support, IvySvn came out of a side project that we worked on
at last.fm so it's been paid for ;) However last.fm doesn't use it any more
(we've moved to Maven) so any future development on this project would be a
labour of love so at that point if you find you need something in it changed
some financial incentive would be most welcome :)
Original comment by massdosage
on 15 Mar 2012 at 3:48
Thanks again. And will most definitely keep you guys in mind. Committing to a
tool has long term consequences. For now I think ivysvn will work fine as I am
gradually migrating to ivy and Nexus Sonotype but the svn solution will meet
our needs for quite some time. Nice work and if we need some development in the
future i will be able to procure some funds as needed.
Original comment by ggb...@yahoo.com
on 15 Mar 2012 at 5:39
Original issue reported on code.google.com by
ggb...@yahoo.com
on 13 Mar 2012 at 10:59