On Thu, Jul 14, 2011 at 08:41:12AM -0700, Mark Diggory wrote: [snip] > At this time there are two approachs to customize your DSpace build. > > (1) use the source distro and change all the files you want and > rebuild the entire sourcetree > > Pro: you can navigate to exactly the source that is being used and > override it directly.
Pro #2: there are many well-understood tools to help you keep in step with new releases. > Cons: > > Maintenance and Tracking of customizations across DSpace versions > requires a developer with extensive knowledge of version control > systems, changes will often conflict with work ongoing in DSpace > releases. Applies equally to approaches 1 and 2. > Local institutional developers altering DSpace internals introduce a > conservative viewpoint into the community limiting the advancement of > the codebase because they actually prefer these customized parts of > DSpace to not change rather than see benefit of new development come > into the Community. Applies equally to approaches 1 and 2. > DSpace source release build process is too long for iterative development > > > (2) use an overlay (works with all webapp projects (xmlui, jspui, oai, > sword, lni, solr) and copy the source files you want to alter/override > into separate dspace/modules/xxx projects, building only those changes > you want. > > Pros: > > Only the code that you've changed need to be rebuilt > > Build Process is shorter > > Models how to extend DSpace via Addons, resulting in less > customization of DSpace internals and greater ease in upgrading a > DSpace instance (of course, this depends on the the local developer > not adopting the practice of overriding existing DSpace classes and > instead applying a process of implementing their own "Service Based" > approach to implement a solution. Assuming that you're lucky enough to want something for which a Service is already defined. If you had to invent a new kind of Service, nobody is ever going to request it until you hack the stock source. See the statistics add-on for an example. Instead of trying to teach or constrain people to never never never touch the source, we should be teaching them how, when necessary, to do it right: o find the right spot; o generalize what you're doing, so that those who follow you won't have to do what you're doing again and again; o discuss with the community; o separate your local concerns into local classes; o contribute your enabling changes back to the community. > Works well IDE's that use maven source artifacts to resolve the source > for a specific java class. > (m2eclipse and Intellij IDEA) > > You can Check out separate modules and via the maven profiles in the > dspace/pom.xml you can build only the source components you want. > > Cons: > > Its not my opinion, but some in the community seem to think that it is > a hinderance if you either need to use an IDE or separately checkout > the code for the module you want to get source from (when doing the > bad practice of overriding classes directly, which we suggest trying > to avoid doing to ease maintenance of your customizations. Or when doing the good practice of trying to understand the code you're interacting with. Me: Hmmm, what does that method actually do? [hover] Rats, the doc comments are worthless. IDE, take me to the source! IDE: That class is not in the workspace. Me: [unprintable]! Where is it? WHAT is it? [examine dependencies, rummage around in scm.dspace.org for a few minutes] There it is. Check out Yet Another Module...now, what was I doing? Cons #2: You just forked DSpace, same as in (1) but covering your tracks. Good luck keeping your local modified sources in sync with the distributed ones. Your SCM tools cannot help you, because they have no way of knowing that dspace-foo/x and modules/foo/x are related. Nor does your IDE. And none of that has anything to do with async. releases. It's does touch on modularity, which enables async. release but also enables other practices which are entirely separate. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart.
pgpkasx9RYGSv.pgp
Description: PGP signature
------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
