Tim et. al., The http://scm.dspace.org/svn/repo/modules directory is intended by me to be the "archetype" for how and where we should be maintaining literally all the modules of DSpace including portions of DSpace API. I understand at the moment it looks a little bit chaotic, but what needs to be understood is (as Tim has suggested) that we can organize things within this space to assure we are appropriately grouping the modules. But what is most critical is the support for individual svn project spaces and release histories for each module.
I argued extensively during my redesign of dspace to use maven in 2006, that many of the individual dspace-xxx modules should have had their own svn project spaces (trunk/branches/tags) so that they could have separate releasing, but the group pushed back excessively on creating more than on trunk at that time. This was not only disappointment to me, but most of our forward motion ceased after the excessive debate and breaking dspace-api up further was never brought to fruition. It took my next initiative to move the SVN repository off of Sourceforge to OSS hosting that finally got a top level directory in place and allowed us to start creating individual separate projects. And, now we have a "modules" and "sandbox" space within the repository. This is where the experimental growth and creation of new addons for DSpace is happening, if your not understanding what is going on in these directories, ask questions and we will do our best to describe why and how specific projects exist. I have to be critical that DSpace Services have no reason to be in the main DSpace trunk. It is a standalone tool with no dependency on dspace-api, this was how it was designed to be. Placing it under trunk actually defeats all the benefits of releasing separately. And to be honest, none one should be locally altering the implementation of the Service Manager codebase in the customization of your DSpace instance. This doesn't mean other committers in the group can't alter the code and contribute improvements to it, everyone is certainly welcome to contribute. Its very serious, you shouldn't be touching this code if you are just customizing your local DSpace instance, this is why its source is separate from the distribution and has separate release cycles. --- Based upon the alternate proposal, I feel that something is being misunderstood about the goals of the Domain Model and original Asynchronous work. The Domain Model ( https://wiki.duraspace.org/display/DSPACE/Refactoring+the+DSpace+Domain+Model) being created as a Addon Project is specifically designed to allow asynchronous release of addons that may be later released as part of the formal DSpace release. The Domain Model, Its corresponding Services and DAO, need to be maintained quite separately from the release trunk to facilitate the asynchronous release process. This is because versioning these API outside of the trunk will allow the following features: a.) Because the Core API (which really have not changed since DSpace has been initially released) doesn't actually need to be rereleased every single version of DSpace, it can be depended on as more stable than the underlying implementation(s), which are currently the target of considerable criticism and interest in reimplementation. Likewise, because it is a "Contract", we can institute policies of maintaining backward and/or forwards compatibility across new DSpace releases. b.) Because of this "Contract", users of the Domain Model wil be insulated from changes to the internal DSpace implementation, their work will be more stable and require less source code merging than the current approach of direct alteration of the codebase or direct overriding of core implementations. c.) Because the Core API would reside outside of the trunk, Addons can be released using it as a dependency and then depended on in the trunk without having to be released / maintained within the trunk. This allows for 3rd parties to have an easier time releasing their addons to DSpace. Likewise, this allows addons maintained in separate organizations to be contributed and released with DSpace without having to drag them into the trunk. Gaining this capability is the absolute reason we are currently striving to complete the work. To give you an example, in 1.6 we were forced to copy dspace-statistics into the trunk because it needed to depend on dspace-api and be depended on by other trunk modules like the dspace-xmlui-api. By eliminating the need to depend on dspace-api and instead on an external release of dspace-core-api, we will be able to move dspace-statistics back out of the trunk and release it on its own version, and include that version into the dspace-xmlui-api/webapp etc. By creating dspace-core-api outside of the Trunk, we are creating a whole new way to interact with the DSpace Domain Model and its underlying implementation. Developer working on DSpace in this new situation only need to checkout the parts of DSpace that they are interested in. On Thu, Mar 31, 2011 at 2:06 PM, Tim Donohue <tdono...@duraspace.org> wrote: > > In other words: We need to make source code easier to work with (or at > least more logical), and not add unnecessary complications or > frustrations to our development processes. > > Just my quick thoughts on this. Definitely feel free to disagree with > anything I've said. I want this to be an open discussion of ideas, so > that we can continue to work quickly towards a common decision around > many of these proposals/vague ideas that have been hanging around for > far too long. > > - Tim I am very confident about contributing the Core Domain Model and Services. I have been working on Asyncronous release for the last year and this work is not as much"coding" as it is the culmination of a great deal of code analysis and research. I will be consolidating the proposals to reflect that they are, in fact, one in the same. I fear that because many do understand the original intentions, they are not understanding the necessity of the work. I will also argue that the changes are not unduly complex and are meant to actually improve the organization of the codebase and make it easier to maintain your customizations, addons, etc. Likewise the work gives the community a template for how the service manager should be used in the DSpace application. For the minor price of altering one line that looks like "public class Foo implements SomeInterface" in the DSpaceObject Classes, we get a explicitly defined API / Contract for the DSpace Domain model. The work to add the Domain Model will actually be an easy merge for those who have customized core dspace classes, as it is literally only changing one line of code per class in dspace-api. Best, Mark -- Mark R. Diggory @mire - www.atmire.com 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Technologielaan 9 - 3001 Heverlee - Belgium
------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
