All, Hopefully I can clarify a bit...sorry for the longer email, but I think it's worth explaining this in a bit of detail.
In DSpace 1.4.x there are several locations that include your JSPs: (1) [dspace-source]/jsp/ -> the out-of-the-box JSPs (2) [dspace-source]/jsp/local/ -> an empty directory specifically for your local customizations. JSPs of the same name will *override* those in #1 above (e.g. /jsp/local/home.jsp overrides /jsp/home.jsp) (3) [tomcat]/webapps/dspace/ -> where the final JSPs are that Tomcat loads your DSpace website from There's actually no true *right* way to manage all your modifications, with the exception of the following rule: *** Never, ever directly modify JSPs that Tomcat uses (#3 above) in your Production installation, as you will be changing the "live" site and may accidentally break it. Beyond that, you have two primary options for how you may wish to manage JSP modifications in DSpace 1.4.x: (A) For most folks, it's recommended (but not required!) to move your modified JSPs from /jsp (#1 above) to /jsp/local (#2 above), to help you better manage which JSPs you've modified in the past. However, when you upgrade, you'll still need to compare all your JSPs in /jsp/local to the updated JSPs in /jsp. There *may* be changes in the latest version of DSpace which could cause your /jsp/local changes to break. (B) As an alternative method, many institutions have begun to store a copy of the entire [dspace-source] within a Version Control System (either CVS or SVN). If you are using a Version Control System, you may find it easier to modify JSPs directly within /jsp/ (#1 above), rather than moving them to /jsp/local. The main reasoning here is that the Version Control System can often better manage your modifications, and can often auto-merge your modifications during your next DSpace upgrade. However, this method is really only recommended for those who are *very* comfortable with Version Control Systems and how they work... Please note, that all of what I said above is *only applicable* for DSpace 1.4.x and lower. DSpace 1.5.x uses the idea of Web Application "overlays" *instead of* the old /jsp/local/ directory. It's a similar concept, but obviously JSPs are put in a different location. More on "overlays" can be found in my "DSpace 1.5" tutorial from JCDL 2008: http://hdl.handle.net/2142/8755 There's also some basic "overlay" examples that Graham Triggs and I presented at Open Repositories 2008: http://www.dspace.org/images/Training_Materials/or2008-dspace-1_5.ppt I hope that helps clarify a bit... - Tim -- Tim Donohue Research Programmer, Illinois Digital Environment for Access to Learning and Scholarship (IDEALS) University of Illinois at Urbana-Champaign [EMAIL PROTECTED] | (217) 333-4648 George Stanley Kozak wrote: > JQ: > > As a person with a MA in Theology, I know how easy it can be to > misinterpret text ;-) Perhaps one of the original DSpace developers could > enlighten us with exactly what this passage means? > >> "7. Your 'localized' JSPs (those in jsp/local) now need to be >> maintained in the source directory. If you have locally >> modified JSPs in your [dspace]/jsp/local directory, you will need to >> merge the changes in the new 1.4.x >> versions into your locally modified ones. You can use the diff command >> to compare your JSPs against the 1.4.x >> versions to do this." >> >> My understanding is that the thrust of the first sentence is just to >> reiterate "never edit files in the web deployment directory." That is, >> [dspace-source]/jsp/local is a source directory, though not a "src" >> directory. >> >> When I read the rest of the above, I interpreted it to mean that local >> changes should go into [dspace-source]/jsp/local, but that you can't >> simply copy over your changed files from 1.3.2 into a 1.4.2 >> installation, or from 1.4.2 into 1.5.x. You need to re-implement your >> changes on top of the new files, but continue to put local changes >> into jsp/local rather than modifying >> jsp------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________ >> DSpace-tech mailing list >> DSpace-tech@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> > > > **************************************** > George Kozak > Coordinator > Web Development and Management > Digital Media Group > 501 Olin Library > Cornell University 14853 > [EMAIL PROTECTED] > 607-255-8924 > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > DSpace-tech mailing list > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
