Thanks for this, Eddie. I just added it to my list of SWORD implementations: http://devguide.thedata.org/features/api/data-deposit
I like how you've separated out your implementation (i.e. FedoraCollectionDepositManager) from the server/library code. Different projects, different git repos. I'm planning on doing the same. On Thu, Jun 20, 2013 at 12:14 PM, Edwin Shin <edwin.s...@yourmediashelf.com> wrote: > Phil, > > There's also the fork of JavaServer2.0 that I did last year: > > https://github.com/mediashelf/sword2-server > > which changed the packaging from war to jar, implemented multipart/related > support and some general maven/dependency maintenance. > > I did that as part of a very limited implementation of SWORD 2 for Fedora: > > https://github.com/mediashelf/sword2-fedora > > -Eddie > > On Jun 20, 2013, at 3:22 PM, LEWIS Stuart <stuart.le...@ed.ac.uk> wrote: > >> Hi Phil, >> >>> I forked https://github.com/swordapp/JavaServer2.0 and implemented the >>> very minimal number of interfaces to get it to respond to some basic >>> SWORD v2 operations such as retrieving a (fake) service document and >>> (the very beginnings of) depositing a binary. >> >>> I called the repo "Minimal viable SWORD v2 server implemented in Java" >>> (though it's hardly viable) and you can find it at >>> https://github.com/dvn/swordv2-java-minimal >> >> Thanks for sharing this. The JavaServer.20 was originally written as part >> of the DSpace SWORDv2 implementation, but it was thought at the time it >> would be worth abstracting out the SWORD part from DSpace part, in the hope >> that this might be reusable. As far as I know, you're the first person to >> try using outside of DSpace (hence the lack of any other implementation or >> past experience). >> >> Richard Jones wrote this and may be able to give you a few pointers, however >> he is offline this week at a conference (OAI8 in Geneva). If you're >> attending Open Repositories next month, I'm sure he'd be happy to say hello >> and talk more about the code. >> >> >>> p.s. I'm growing concerned that this mailing list is so quiet (and >>> only admins can see the number of people subscribed). Have people >>> moved on from SWORD to some other standard? If so, which one? >> >> I just checked - there are 175 subscribers to this list. >> >> As far as I know, SWORD is the main contender in town when it comes to a >> standardized deposit interface to this type of repository. I've also >> wondered about the quietness of this list. I think there may be a few >> reasons: one, is that a lot of repository users are still grappling with >> their repositories, without yet getting as far as accepting remote deposits. >> Second, SWORD doesn't yet really have an active community sharing deposit >> tools. Partly this is because many uses of SWORD will be very specific >> point-to-point integrations, which might not be of interest to too many >> others. >> >> It would be good to hear a wider discussion about this, and how we share >> more about our individual uses of SWORD. >> >> Thanks, >> >> >> >> Stuart Lewis >> Head of Research and Learning Services >> Deputy Director Library & University Collections, Information Services >> University of Edinburgh >> stuart.le...@ed.ac.uk >> -- Philip Durbin Software Developer for http://thedata.org http://www.iq.harvard.edu/people/philip-durbin ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ sword-app-tech mailing list sword-app-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-tech