Well, this is all a bit tangled. Themes are a special case. You can develop them *anywhere*, so long as a copy of your Theme gets put where DSpace looks for it by the time you want to try it out. It doesn't have to be *anywhere* in the DSpace source tree because it isn't compiled against anything; it's just a pile of XML and (maybe) static content.
More generally, many pluggables (such as aspects) can be developed out-of-tree, JARed up and dropped into place without going through the DSpace packaging/installation process at all. Just configure them in. Maybe this is part of what we should be helping people to understand. On Sat, May 28, 2011 at 02:18:24PM -0700, Mark Diggory wrote: [snip] > I think rather than core developers recommending altering parts of the > codebase that are either considered wise to keep ones hands off, we need to > understand why we still want to promote doing this and find yet more ways to > improve the process of getting the application developer a cleaner, more > well documented API to program changes against (rather than "hacking the > core"). Well, one reason is that it is such a PAIN to manually copy the sometimes extensive changes in a new DSpace version into altered copies in /modules, check that you found everything, check that you didn't put something in the wrong place because the line numbers don't match, check for colliding changes, and lots of other stuff that an SCM will take care of for you if you keep your altered copies where it looks for them. Doing the equivalent (/jsp/local) between 1.1.1 and 1.2 was so awful that I taught myself to use SVN and to maintain parallel vendor and local branches solely to avoid that pain -- and it was well worth my time and effort. I never went back to overlays. Having a tool that understands what I'm trying to do was just so much better. Most of the process of merging updates is mechanical, and people do mechanical tasks poorly. That's why we invent machines. We could whip up a 3-way merging Maven plugin that knows how DSpace is organized. Is that really a good idea? Maintaining parallel lines of code development is not DSpace's purpose. Shouldn't we use tools that *were* made for the purpose, that already exist and are well understood? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart.
pgpFe2GJdIOqS.pgp
Description: PGP signature
------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
