[
https://jira.duraspace.org/browse/DS-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22237#comment-22237
]
Mark Diggory commented on DS-1005:
----------------------------------
Responding to Richards original comments:
> It was my assumption that this code would be of interest, particularly as
> it will be shipping as standard in the next versions of EPrints and Fedora,
> but that is a decision for the DSpace community, and not one for me to press
> upon you. Contrary to Mark's opinion, I'd say that there is benefit to
> SWORDv2 being part of the dspace trunk for the following reasons:
To clarify, I am not suggesting swordv2 "not" be part of the DSpace
distribution, but that its code be centrally managed, so that all projects
can benefit from eachothers work on it.
(a) we can benefit from bug fixes across all applications that use SWORD api
and Foresite (Fedora) in one central codebase rather than two separate
codebases.
(b) code that is reusable (foresite) can be easily picked up as a separate
dependency without being confused as strictly "sword", I'm already utilizing
it separately for another project.
> 1/ If it is not released synchronously then I'd expect fewer people to use
> it
Clarficiation: The sword webapp and its api would stay in dspace trunk.
Foresite and other sword api code thats used on other repositories as well
would be released separately (via the "modules" project).. Basically, any
thing that doesn't have a dependency directly on DSpace is best treated as a
separate addon module to be maintained in the "modules" directory and
released separately (the dspace services methodology).
> 2/ Until DSpace has a well developed "add on" mechanism for external modules
> (see, for example, the EPrints Bazaar), I'm not sure how well releasing
> modules separately is going to go. Perhaps there is some other guidance on
> this that I've not yet seen, though?
There is a well defined addon mechanism for developers, unlike EPrints
Bazaar, it is for developers, not for system admin / endusers. Its called
"Maven" and you can add anything you want to DSpace via the modularity
mechanisms that Maven provides. Ironically, at this time, this is the exact
same mechanism that Fedora uses.
> 3/ At the end of the SWORDv2 project we do not have any immediately prepared
> funding for ongoing development. This means that we won't have the resources
> to manage our own external module in perpetuity. A better solution for the
> code is for it to be owned by the DSpace community, while we seek further
> funding to manage the specification and the common libraries (this is
> underway, fyi).
An even clearer reason not to "dump" the codebase into trunk IMO,
basically, this means that without adoption, SWORDv2 could easily place us
in the position we are now in with LNI. We maintain a codebase in trunk
that 90% of the committers do not understand at all. We run the risk of
this unused code actually "limiting" the ability of DSpace to evolve and
improve its core infrastructure. So, IMO, while I highly thank you guys for
the great work and effort to get this next version of SWORD delivered to us.
We want to keep the management of this codebase optimal for the larger
community it is utilized within. We reserve the right as individual
committers to impose the direction this codebase should be tailored for
optimal support by that community. This is why veto rights are so powerful
on code contributions.
> 4/ EPrints and Fedora will provide SWORDv2 support as standard in their
> upcoming releases this year.
Here is an example of an opportunity for Fedora and DSpace developers to
come together in collaboration. To clarify.... one codebase for the SWORD
front end and Foresite could be maintained within the Duraspace umbrella.
The dependencies on this codebase utilized by both DSpace and Fedora, who
are both contributing resources to properly support the functionality. This
means less work for "you" in the future for SWORD maintenance and "direct
benefit" by sharing solutions immediate across both DSpace and Fedora.
> SWORD v2 has a number of external dependencies, and the SWORD team have also
> provided common code libraries for generic server and client operations, for
> the ease of all SWORD developers, not just the DSpace ones. It is our aim
> to put these into the central maven repository, but this has not yet happen
> primarily due to time constraints, and I am currently working on submitting
> the libraries to sonatype, which could take some time due to the vetting
> procedures and requirements that they have (including control of the domain,
> and the relationship between the version control location and the org.
> swordapp domain).
In the JAVA cases, my opinion is that our focus should be on getting these
in, I am here to shepard you through this process. We've been here doing
this for years now. It would behove you to utilize the Duraspace community
in this area rather than "going it alone". I think you construe my points
above to mean that I don't want SWORDv2 JAVA modules in DSpace, please
understand that is not what I'm saying, I'm saying the right place for these
is in Duraspace so they can be shared across the platforms rather than
embeeded into DSpace and Fedora as separate codebases.
> I'm not sure that having common libraries which work for a multiple
> environments should be considered a problem - this is good code re-use, and
> gives other SWORD developers a leg up to deal with the boring bits that are
> the same everywhere. The code base is not forked, it is simply that there is
> a DSpace implementation of the common library's interfaces; this is good
> design as far as I'm concerned. Is there a particular issue with the
> DSpace implementation relying on external common libraries?
This is not what is presently in the codebase. You've forked your entire
set of common libraries in DSpace by copying it into the tree as source. Is
it the plan to do the same for Fedora as well? Thus if theres a bug or fix
that needs to happen, it is now bound to the DSpace release cycle and users
will need to patch and maintain SWORD source to be able to utilize these
fixes. If they are separate releases, then users of DSpace and Fedora can
upgrade the dependencies in their dspace-parent pom to use the new release
and immediately benefit from the bug fix. Think about this from a security
standpoint, do we really want to release an entire maintenance release of
all versions of DSpace that use SWORDv2 if a security issue arises, wouldn't
it be so much easier just to release the fixes for SWORDv2 separately and
alert the community to just change the version of the SWORD libraries they
are using? This is certainly much easier than forcing all DSpace
installations to have to merge the fixes in source to get such an update.
(This is my longstanding argument for asynchronous release, its easier to
get fixes into the deployments without creating massive "developer
activities" for your endusers).
> The Foresite library, which is currently icluded as source in the DSpace
> SWORDv2 module, has already had its pom prepared for submission to the
> central maven repository, but I couldn't submit myself it as I don't control
> the org.dspace domain that the code lives under. A way forward on this or
> any assistance would be gratefully received.
I'm here, lets get you the help you need. This is why I'm suggesting putting
the code under http://scm.dspace.org/svn/repo/modules. Because we have all
the credentials in place and if the Foresite and SWORD projects have a
"termination date" for development support, placing these nto Duraspace
seems sensible for acquiring a community of developers to support it going
forward, does it not?
> With regard to licensing, the code can be considered in this case to be a
> code contribution to the DSpace Community, and if it is to be part of the
> standard distribution then we are very happy for it to use the standard
> DSpace licence. It only doesn't have a licence at this time due to lack of
> a discussion around it rather than any intent on our part. If we do not wish
> to accept SWORDv2 as a part of the out-of-the-box DSpace, the SWORD team
> would just licence it appropriately (and probably under the same licence as
> DSpace anyway).
The release process actually forces this issue, releases cannot be cut
without the DSpace licensing on appropriate source files, the maven release
process fails appropriately to stop this from happening.
> It's worth adding that I'm not a maven expert (I rely on it exclusively for
> dependency resolution generally), so would very much appreciate some
> guidance in the aspects discussed above which are regarded as "easy" by the
> experts here.
Again, I'm here. Maybe its best to schedule an IRC meeting to discuss the
topic more effectively.
Cheers,
Mark
> SWORD v2 implementation for DSpace
> ----------------------------------
>
> Key: DS-1005
> URL: https://jira.duraspace.org/browse/DS-1005
> Project: DSpace
> Issue Type: New Feature
> Components: SWORD
> Reporter: Stuart Lewis
> Assignee: Robin Taylor
> Fix For: 1.8.0
>
> Attachments: dspace-swordv2.zip, swordv2.patch
>
>
> Ticket for the addition of SWORD v2 to DSpace 1.8. When building, you'll
> need to make sure you update dspace.cfg to include the new config options.
> Before 1.8 launch, we'll move these into modules/swordv2.cfg
> To test:
> 1) Apply patch
> 2) Unzip zip file to create new dspace-swordv2 module
> 3) Do the maven dance, deploy, visit /swordv2/servicedocument, enter DSpace
> username and password, check a service document is shown
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
