Hi Mark, I think the vision of a distributed modular DSpace architecture is a good one. I think though, that we need to distinguish between what is versioned together, and what is distributed together. The default DSpace distribution ought to support out-of-the-box the most important and useful services which repository systems should offer (as defined by our community), irrespective of where they are stored for development. To use Eclipse as an example: it drives me mad that it doesn't come with all the tools I actually need, and you have to go hunting about to find the right thing, and install a whole bunch of random kit until you get it right. This sort of modularity is great for developers, but unless properly managed it is not so obviously great to the users.
Due to the current limitations of the maven build system, which does a fine job of managing source code modularity, but cannot yet cope with the more subtle angles of adding new modules, many existing modules (sword included) cannot be trivially downloaded and installed. They require modifications to the dspace pom.xml, additional configuration, and files which are not dealt with by the build process must be included, and so forth. Therefore, it makes sense that these be released together ready-integrated, as it were, when stable releases are announced. In summary, I don't mind where dspace-sword is versioned, but I do think it's important that it gets released in the same package as the main DSpace. If this means putting it in trunk alongside other modules in the same position such as the LNI (which wasn't in trunk for 1.4.2) then that has to be the interim solution. Cheers, Richard > While I don't discount the benefits of delivering the sword service > with the dspace distribution. We are really reaching a point where we > need to consider if it is better to manage each of these addons > independently in different version trees and simply combine them > together into a common package for the distribution release. I think > we are realizing we need to move to a distributed support and > development model because of the growing size of our community and the > diversity of directions we all want to take the codebase in. The > benefit of such a model means that a development lag in any one addon > should not limit the successful release and update of other addons. > I'm pretty concerned that if we keep placing more and more addons > under the sf.net/dspace/trunk. We will see the same > development entanglement and scaling issues we are attempting to clear > up. > > I've been working to establish a layout within the dspace sandbox > that adequately gives addons room to advance and release > independently. This means reserving svn trees (trunk/branches/tags) > as a convention for each addon and using common > project management tools to handle releases. Please see the following > as an example. > > our addon projects space (anyone can request an addon project here: > http://dspace-sandbox.googlecode.com/svn/modules/ > > An example project (dspace-sword) > http://dspace-sandbox.googlecode.com/svn/modules/dspace-sword/trunk/ > > In the real world, these projects will have different development and > release schedules and trying to maintain them in a common versioned > tree would slow the release of all to the that project whose > development/stability was lagging. > > To give you a real examples, the Eclipse (www.eclipse.org > <http://www.eclipse.org>), the Maven (maven.apache.org) and the Spring > (www.springframework.org <http://www.springframework.org>) communities > all maintain their, plugins/modules as separately versioned entities > and work to aggregate these entities into one common release on a > "seasonal" period, but any one module/plugin can release new versions > of itself on a faster/slower cycle as seen fit. I think this is a > very important aspect of the "Bazaar Economy" I seek to introduce into > the DSpace Community. > > All that said, I still support adding sword to the trunk, but only > under the pretense that we are outgrowing S.F. and need to establish > our own SCM service with greater control of organization and access > control. And that at such a time we will consider establishing a > smaller core (just "dspace" and "dspace-api" projects) and a space > similar to dspace-sandbox for all other addons (xmlui, jspui, oai, > srw, sword, lni, ...) with independent version trees. > > Cheers, > Mark > > On Dec 10, 2007, at 5:38 PM, Dorothea Salo wrote: > >> On Dec 10, 2007 11:52 AM, Richard Jones <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >>> As other repository platforms will be offering this service, we would >>> like to include it in the general release of DSpace. Are there any >>> objections to this? If possible this would be for 1.5, otherwise >>> for 1.6. >> >> Objections? Goodness, no. The sooner the better. A big +1 from me, >> with thanks! >> >> Dorothea >> >> -- >> Dorothea Salo [EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> Digital Repository Librarian AIM: mindsatuw >> University of Wisconsin >> Rm 218, Memorial Library >> (608) 262-5493 >> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> _______________________________________________ >> DSpace-tech mailing list >> DSpace-tech@lists.sourceforge.net >> <mailto:DSpace-tech@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/dspace-tech > > > > ~~~~~~~~~~~~~ > Mark R. Diggory - DSpace Systems Manager > MIT Libraries, Systems and Technology Services > Massachusetts Institute of Technology > > > -- Richard Jones Research Engineer, HP Labs eml: [EMAIL PROTECTED] blg: http://chronicles-of-richard.blogspot.com/ ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
