Hi Mark,
Thanks for this, very helpful, comments inline ...
>> 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
>
Ok, fantastic, that's very helpful. So, you are happy that the java-common
in the svn is superseded by the SWORDv1.1 in Github? I've updated the name
of the SWORDv1.1 in github to SWORDv1-Common, to reflect this.
>
> 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.
>
Do you feel that the general applicability of the DSpace modifications is
in question? We could tag the existing common code, and then branch, and
merge with the DSpace version, and tag that as being DSpace specific (or
more generally, using files instead of inputstreams); that would at least
alleviate DSpace of the burden of maintaining this code, and we could then
work towards a single common library which takes all use cases into account.
I would, in general, be very happy to merge the DSpace modifications into
the main library, as this would no doubt make everyone's lives slightly
simpler in the long run.
Cheers,
Richard
>
> 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
>
>
>
--
Richard Jones,
Founder, Cottage Labs
t: @richard_d_jones, @cottagelabs
w: http://cottagelabs.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
sword-app-tech mailing list
sword-app-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sword-app-tech
