"JavaSVN is a pure java Subversion (SVN) client library." This library is required by SVNClientAdapter, which is required by Subclipse, a Subversion plugin for Eclipse. I hope to provide ebuilds for these shortly. The upstream tarball contains a lot of unnecessary dependencies. I have provided a stripped down tarball here. http://www.kerami-tek.com/~chewi/javasvn-0.8.8.1.tbz2
Created attachment 63352 [details] javasvn-0.8.8.1.ebuild
Created attachment 63353 [details, diff] build_xml.patch The build.xml file has to be modified slightly because the dependencies are being provided externally.
Oh and this uses a unique license, which can be found here at... http://tmate.org/svn/license.html
Use java-config --classpath=<pkg>,<pkg2> or java-pkg_jar-from to set the classpath.
Created attachment 63520 [details] javasvn-0.8.8.1.ebuild I have now used java-pkg_jar-from for JSch but it doesn't work with svn-javahl as this was not installed using dojar. This is part of the Subversion package and that ebuild would need to be modified in order to fix this.
Ah damn, wait a minute. I tried the same thing on svnclientadapter and it didn't compile. I then realised that it wouldn't have compiled here either but it does because it seems JSch is only an optional runtime dependency. This ebuild is still okay (apart from the svn-javahl thing) but in order for me to do svnclientadapter, how would I get the entire classpath from the eclass after a series of calls to java-pkg_jar-from? I could just run java-config again but that seems like unnecessary work. I've looked through the eclass but I can't seem to find anything like java-pkg_getclasspath.
Here's how the java ebuilds should be done: 1. delete the packed jars 2. use ant properties to set the location of the antflags="${antflags} -Dlib.location=$(java-config -classpath=<pkg>) 3. if the build.xml doesn't support these properties it is preferred to make a patch and submit it upstream. 4. You can use java-pkg_jar-from the replace the packed jars with symlinks to system jars, but 2 and 3 are preferred. See: http://gentoo-wiki.com/Gentoo_Java_Policy You should submit a bug for Subversion if one doesn't already exist and make this bug depend on it. All jars should be installed using java-pkg_dojar if at all possible. You don't also need to install the COPYING file because it should already be in /usr/portage/licenses. I also think you also can't have spaces in the name of the license because spaces are used to separate multiple licenses. If JSch is really only needed to run this, DEPEND and RDEPEND should reflect that. It should also be under a use flag. Ebuilds have these many issues that can sometimes be a pain for beginners (I know they have been for me), but don't let it beat you and keep up the good work.
I've just read through that document. I didn't understand what java-pkg_jar-from was doing before. It makes sense now. The document doesn't mention the other method and if you were to use that method, it wouldn't put the dependency information into the package.env file when calling java-pkg_dojar. There are also some inconsistencies. The document states that Javadoc stuff goes into /usr/share/doc/${PF}/html/api and that the java-pkg_dohtml command takes a list of directories. The eclass is doing neither of these things of the moment. What java-pkg_dohtml actually does is call dohtml and dohtml expects files, not directories. The -r option needs to be added for starters. dohtml also inserts the files into /usr/share/doc/${PF}/html and not /usr/share/doc/${PF}/html/api. These may be minor points but the eclasses are supposed to make life easier and the policies really should accurately reflect what is actually happening. I still think there should be a function in the eclass that returns the classpath that has been generated from several calls to java-pkg_from-jar since this function is calling java-config --classpath and you'd just be calling it again. I'll file a new bug for Subversion.
Yes, our eclasses and documentation could need some improvement. Most of these issues should already be known to us. Our tools are under improvement by axxo at the moment and will hit the official tree at some point. If you want to discuss these issues further, you can come meet us at gentoo-java@freenode. I am called Betelgeuse there.
Created attachment 63716 [details] javasvn-0.8.8.1.ebuild Assuming axxo doesn't make too many changes to his new eclass or the patch I sent him then this ebuild should work when the new stuff comes out. It'll have to be put on hold until then.
Actually I'm wondering if jsch should be a compile-time dependency. It would normally only be a run-time dependency but the ebuild needs to know its location in order to create package.env.
Closing this because it is in chewi-overlay.
Please don't resolve until it is in the main tree.
This ebuild request has been reported in 2006 (!). Do we still want it added to the tree ? If someone does, please comment. Otherwise I will close this bug. @James: you've reported this bug. Please let us know. Thanks.
JavaSVN later become SVNKit. This is still maintained. We have an SVNKit ebuild in java-overlay but it's old. It is used by these projects. http://en.wikipedia.org/wiki/SVNKit#Adoption Of these, I think we've only ever packaged Subclipse but that's since gone. It's an Eclipse plugin and we don't even package Eclipse any more, never mind the plugins. It wasn't a direct dependency but used svnclientadapter. See bug #98948 about that. We would obviously like to package some of those aforementioned projects but they're not easy ones so I would probably close this as WONTFIX and remove the ebuild from java-overlay.
Thanks James. Closing it then.
