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
> 

------------------------------------------------------------------------------
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

Reply via email to