From: Mark D. <mdi...@at...> - 2012-05-02 23:56:52
|
On Wed, May 2, 2012 at 1:44 PM, Richard Jones <ri...@co...>wrote: > > http://sword-app.svn.sourceforge.net/viewvc/sword-app/java-common/ > Java common client and server code for 1.x. This is pretty much > comprehensible, but there are a variety of nested tags/branches/trunk > structures, and without picking through the commit logs (and maybe not > even then) I'm not sure what's supposedly the operational tip of this > code. > This was originally the important stuff we need for DSpace, which I had runa pilot import to github here. https://github.com/swordapp/SWORDv1.1 Which was also used to issue a SWORD 1.1 release to the maven central repository a few months ago when working on the dspace maven project consolidation. I validated that the code used in the release was the last stable revision that was used in other projects. http://search.maven.org/#artifactdetails%7Corg.swordapp%7Csword-common%7C1.1%7Cjar Problem is, the DSpace AIP work altered features of this library and DSpace still maintains its own copy of the code here https://github.com/DSpace/DSpace/tree/master/dspace-sword/dspace-sword-api/src/main/java/org/purl/sword Ultimately, if those changes could be adopted by the 1.1 common project, DSpace could stop replicating this code and it would be back under the umbrella of swordapp. But that introduces those changes to anyone else using the api (mostly switching from InputStreams to java Files and the mode of transferring the package into DSpace Packagers, point being, the temp file was already getting created earlier in the upload process) As I suggested earlier, it'd probably be easiest to pull each of these separate svn project structures in as separate git repositories, especially if some of the code is of questionable long term value. Mark -- [image: @mire Inc.] *Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>) *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010* *Esperantolaan 4, Heverlee 3001, Belgium* http://www.atmire.com |