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 g...@github.com: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 <claudia.juer...@ub.tu-dortmund.de>
> 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/webapp/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
> > DSpace-tech@lists.sourceforge.net
> > 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
> DSpace-tech@lists.sourceforge.net
> 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
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
