Tim,
The challenge with most of these projects is maintenance.
I will say this, we need to build a scalable contributor community around
these separate "modules" (including everything in dspace-sandbox), this
means that we do need to have some leadership coming out of the community
that will work to maintain them. This is the historical dilemma with the
commiters group, not enough resources to take all these separate
patches/addons and maintain them cleanly (especially with the state of the
patch queue we are so desperately trying to escape from underneath). Now its
much the same here as well, albiet with an even looser set of criteria for
participation as a commiter.
The dspace-sandbox is broken down into the following organization:
DSpace Addon Modules:
http://dspace-sandbox.googlecode.com/svn/modules/
A place for addon modules for dspace (including the internationalization
project for the current DSpace releases)
*DSpace Prototypes:*
http://dspace-sandbox.googlecode.com/svn/prototypes/
A place for experimentation's on dspace architecture.
Each of the "Addon Modules" has its own svn project structure and versioning
to allow it to be ported independently of other projects, this allows the
community to place its effort where it wants to, and it allows our modules
to complete in a free market ecology for our precious developer resources.
I had started to test a new provider for maintaining sourcecode within the
DSpace community... the OSUOSL. They kindly are willing to donate their
virtualization resources for the DSpace community. And I started
experimenting with setting up a svn repository on a virtual machine located
there...
https://dspace.osuosl.org/svn/
with a fine grained access control administrative application that I've also
been testing for managing user rights within that repository...
https://dspace.osuosl.org/login.php
This could provide a home for DSpace modules that is all under one umbrella
rather than "separate" and "unequal" source code repositories peppered
around GoogleCode and SourceForge. But alas, without community buy-in,
something like this will not get traction beyond an experimentation phase.
Thus its about time I brought it into the community and started talking
about it here. This is Virtual Machine which we can pretty much do what we
want to with it. I have some administrative access at this time, and as
needed we can request more.
Finding and search for these modules is going to require the community
invest in documenting and marketing them as solutions. This means:
1.) We need to agree on a location that we document and access our modules
via.
2.) That location needs to be scalable, to hold lots of projects as our
community becomes health and diverse.
3.) That location needs to be kept accurate and up to date, modules need to
document on which versions they are supported and who is responsible for
maintaining them
4.) We need to protect maintainers for hurting each others projects
(accidentally of course).
5.) That location "NEEDS" to be under the umbrella of the Foundation, the
Foundation and the Community need to be synonymous.
If coming to a decision about these projects availability is not something
we can tractably approach via the pilot I've been experimenting with. Then
I recommend you put your work into the sandbox modules using the appropriate
svn/maven project structure and documentation.
cheers,
Mark
On Mon, Mar 16, 2009 at 12:12 PM, Tim Donohue <[email protected]> wrote:
> All,
>
> I know this topic has been touched upon briefly in past discussions, but
> I'm wondering if the DSpace Community has any
> suggestions/recommendations on how we can best *share* custom-built,
> *production-quality* DSpace Modules that have not been fully accepted
> into a DSpace release.
>
> I know we have an SVN "sandbox" area on GoogleCode. But, in general it
> does not seem to support easily finding/searching these modules, other
> than maybe adding a page to the DSpace Wiki to find them. In addition,
> it's unclear if these sandbox modules are also available via Maven
> Central Repository (they don't seem to be), which would be more ideal
> for production-quality modules.
>
> A part of me even wonders whether the "sandbox" is the most appropriate
> place for production-quality modules (rather than the
> proof-of-concept/prototypes that usually appear there).
>
> I'm asking all this because I now have three production-quality custom
> DSpace 1.5.1 Maven modules which I'd like to make available more widely
> and allow others the opportunity to use, modify & help support:
>
> (1) Maven module for Delegated Administration (Community Admins, etc.) -
> Based on Andrea Bollini's patch with updated bug fixes, etc. [WARNING:
> Overrides some classes in dspace-api]
>
> (2) Maven module for basic Embargo/Access Restriction functionality -
> Based partially on U Michigan's embargo patch, with extra features, bug
> fixes, etc. [WARNING: Overrides some classes in dspace-api]
>
> (3) Maven module for basic Download Statistics - Based partially on old
> stats code (2-3 years old) from U of Rochester, and updated/migrated
> through the years...these stats are entirely DB driven and currently do
> not parse DSpace log files
>
> All three of these modules are now in production in our local repository
> (IDEALS): http://www.ideals.uiuc.edu/ They are all standalone Maven
> projects which work with DSpace 1.5.1 (XMLUI only at this time). I'd
> like to figure out the best way to make these available to the community
> at large.
>
> Suggestions from fellow developers/community members welcome! Is the
> sandbox the most appropriate place for these addons? Or is there
> another area where we should start to make space for more "mature" addons?
>
> - Tim
>
>
> --
> Tim Donohue
> Research Programmer, IDEALS
> http://www.ideals.uiuc.edu/
> University of Illinois
> [email protected] | (217) 333-4648
>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
--
Mark R. Diggory
@mire
http://purl.org/net/mdiggory/homepage - Bio
http://www.atmire.com - Institutional Repository Solutions
http://www.togather.eu - Before getting together, get t...@ther
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
