Thanks, Peter, that's a really cool overview of your development process, using GIT! I followed it all the way until the paragraph staring "Going further" where you start to describe dev/staging/production/manager processes, and perhaps it's just that GIT is still totally foreign to me, but it sounds like you have a process that could be very beneficial to emulate, if you're working in a multi-developer environment. I wonder if you would be able to sketch up some diagrams to go with that last part? Also, if you have any recommendations for further reading on development with GIT, that would be great. Thanks!
--Hardy > -----Original Message----- > From: Peter Dietz [mailto:[email protected]] > Sent: Friday, November 19, 2010 11:11 AM > To: [email protected] > Subject: Re: [Dspace-tech] JSPUI Customization > > Hi, > > I used to follow the put everything in dspace/modules/<webapp-name>/... > but I found that to be duplicate work, as I would develop the feature in > dspace-jspui, then once it was working well, I would copy it to > dspace/module/jspui, and clean up dspace-jspui. However, if you have a > good VCS/SCM (source code version control), then it might work better to > keep a "dirty" dspace-source. > > Essentially you can leave your changes in dspace-jspui, do regular mvn > package, ant update, then when you have to upgrade to 1.7, do directory > diff between all of your modifications and the version you started from > (1.6.2). Then do a clean checkout of 1.7.0, and apply all of your > customizations to the 1.7 dspace-jspui code. A little tedious, but > upgrades are at most once a year, where as development might be daily. > > I don't think this advice/approach is in the DSpace documentation, but I > find it to be the best for me. Also for version control I use GIT, so > that will be what the advice below uses. > > My development flow is essentially this: > > ## Get a copy of dspace source code from a stable tag. I don't recommend > git svn clone ... because thats really slow as it gets the entire > project history (5+ years), which is useless to you locally. > svn export http://scm.dspace.org/svn/repo/dspace/tags/dspace-1.6.2/ > dspace-source > cd dspace-source > > ## Initialize a Git Repository > git init > > ## Ignore the compiled output directories from version control > echo "target/" >> .gitignore > > > ### Advanced Stuff so that when you clone your git repository > (check it out to a new directory), that you don't get maven compile > problems. > ## Because git only files (and not empty directories), ensure that > the webapp directories exist > mkdir -p dspace/modules/jspui/src/main/webapp > dspace/modules/lni/src/main/webapp dspace/modules/oai/src/main/webapp > dspace/modules/solr/src/main/webapp dspace/modules/sword/src/main/webapp > dspace/modules/xmlui/src/main/webapp > > ## And add dummy files to the webapp directories, so that git > tracks the webapp folders to exist. > touch dspace/modules/jspui/src/main/webapp/.gitignore > dspace/modules/lni/src/main/webapp/.gitignore > dspace/modules/oai/src/main/webapp/.gitignore > dspace/modules/solr/src/main/webapp/.gitignore > dspace/modules/sword/src/main/webapp/.gitignore > dspace/modules/xmlui/src/main/webapp/.gitignore > > > ## Add all the files to the git repository > git add . > > ## Commit the change > git commit -a -m "Initial Import of DSpace 1.6.2" > > ## Optionally make yourself a tag (i.e. name the commit) so that you > always know where the clean 1.6.2 was. > git tag -a DSPACE162 -m "Clean DSpace 1.6.2" > > > > ### Optional: Go to github.com (or your local central git > repository server) and create a repository. > ## Add a remote for the central repo, and push your code to it. > git remote add github [email protected]:myusername/myproject.git > git push github master > > > > Thats all the prework to get started doing DSpace development in Git. > I'll show a little example of how you might do some changes, and use git > to track all of that. > > Say you want to edit in JSPUI the community-list.jsp and add an > expand/collapse buttons for the list. We'll start a new development > branch to do this, edit the file, commit it to the development branch, > and then merge it back into master (trunk). > > ## Create an appropriately named branch > ~/dspace-source[master]$ git checkout -b comlist-expand-collapse > > ## Edit the file, make your changes to add the functionality you wanted. > ~/dspace-source-mine[comlist-expand-collapse]$ vi dspace-jspui/dspace- > jspui-webapp/src/main/webapp/community-list.jsp > > ## Commit the change. Notice that we're on the comlist-expand-collapse > branch > ~/dspace-source-mine[comlist-expand-collapse*]$ git commit -a -m "Added > expand/collapse buttons to the community list" > [comlist-expand-collapse 0885433] Added expand/collapse buttons to the > community list > 1 files changed, 1 insertions(+), 1 deletions(-) > > ## Jump back to master > ~/dspace-source[comlist-expand-collapse]$ git checkout master > Switched to branch 'master' > > ## Merge the changes of the development branch into master > ~/dspace-source-mine[master]$ git merge comlist-expand-collapse > Updating 1e73bb7..0885433 > Fast-forward > .../src/main/webapp/community-list.jsp | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > ## Push the changes to your central repository > ~/dspace-source[master]$ git push github master > > > > > > Going further, I use master as the baseline for across-the-board > features added to production, staging, development. Then new features > get developed in a developer-1-feature-A, developer-1-feature-B, ... > branches, which once fixed up gets merged into the staging branch for > testing, once its tested, verified, and approved it gets merged into > production and master. > > I've also wiped out dspace/config, and made it a git submodule (similar > to svn external), in there I have dspace/config branches for production, > staging, developer-1, developer-2, ... so that we can all share the same > source code improvements, but keep the input-forms, passwords, database > names, assetstore locations, webui styles, etc all separate. > > Not using dspace/module overlays, and using a single repository for all > lines of development definitely adds a bit of complexity, but if you're > game for doing things a bit smarter then it adds up to being worth it. > > > > -- > Peter Dietz > Systems Developer/Engineer > Ohio State University Libraries > > > > > 2010/11/19 Claudia Jürgen <[email protected]> > > > Hello Shaun, > > the customizations should be in: > [dspace-source]/dspace/modules/jspui/src/main/webapp/... > to be available during build. > During build these do overlay the defaults. > > After having put your customized jsp's there you got to rebuild and > redeploy your application. > > Hope that helps > > Claudia Jürgen > > > Am 19.11.2010 08:13, schrieb Shaun Donovan: > > > Hi all. > > > > I would like to find out where I should keep my customized jsp > files > > (layout/header-default.jsp) so that they are implemented if I > rebuild > > the application. The Documentation states: > > > > If you wish to modify a particular JSP, place your edited version > in the > > [dspace-source]/dspace/modules/jspui/ > > src/main/webapp/ directory (this is the replacement for the > > pre-1.5 /jsp/local directory), with the same path as the > > original. > > > > Then they give an example: > > > > To edit [jsp.dir]/community-list.jsp, the customized version must > go > > in : > > > > [jsp.custom-dir]/dspace/modules/jspui/src/main/webapp/community- > list.jsp > > > > What they don't tell me is what [jsp.dir] or [jsp.custom-dir] is > (are > > they the source or target directories). > > > > I have tried all kinds of variations without success, the default > files > > get deployed. > > > > So, my source code is in /dspace-src, and my built application > > is /dspace. > > > > Am I supposed to put my customizations in > > /dspace-src/dspace/modules/jspui/src/main/webapp/dspace- > src/modules/jspui/src/main/webapp/layout/header-default.jsp > > > > I have tried this as well as > > /dspace- > src/dspace/modules/jspui/src/main/webapp/dspace/modules/jspui/src/main/w > ebapp/layout/header-default.jsp > > > > as well as > > /dspace-src/dspace/modules/jspui/src/main/webapp/layout/header- > default.jsp > > > > but all to no avail. > > > > Any help would be greatly appreciated. > > > > Shaun. > > > > > > > > ----------------------------------------------------------------- > ------------- > > Beautiful is writing same markup. Internet Explorer 9 supports > > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& > L3. > > Spend less time writing and rewriting code and more time > creating great > > experiences on the web. Be a part of the beta today > > http://p.sf.net/sfu/msIE9-sfdev2dev > > _______________________________________________ > > DSpace-tech mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/dspace-tech > > > -- > Claudia Juergen > Universitaetsbibliothek Dortmund > Eldorado > 0231/755-4043 > https://eldorado.tu-dortmund.de/ > > > ------------------------------------------------------------------- > ----------- > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating > great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech > > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
