นโยบายการจัดการความรู้ มหาวิทยาลัยสงขลานครินทร์ 1.ให้ใช้เครื่องมือการจัดการความรู้ผลักดัน คุณภาพคน และกระบวนทำงาน 2.ส่งเสริมการแลกเปลี่ยนประสบการณ์การทำงาน จากหน้างาน 3.ส่งเสริมให้มีเวทีเรียนรู้ร่วมกัน
อ่าน: 7989
ความเห็น: 0

DSpace: JSPUI Customization [C]

(By Peter Dietz, Systems Developer/Engineer, Ohio State University Libraries)

## 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/
[scm.dspace.org] 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 [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 git@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.

###

An inspiring read was a blog post about a git branching model. Which starts ut with a pretty intimidating/impressive/informative graphic:
http://nvie.com/posts/a-successful-git-branching-model/

Further reading:
-- http://progit.org/book/
-- http://git-scm.com/documentation
-- http://help.github.com/
 

หมวดหมู่บันทึก: พัฒนางานประจำ
คำสำคัญ (keywords): dspace  jspui  customization
สัญญาอนุญาต: สงวนสิทธิ์ทุกประการ Copyright
สร้าง: 20 พฤศจิกายน 2553 09:34 แก้ไข: 20 พฤศจิกายน 2553 09:55 [ แจ้งไม่เหมาะสม ]
ดอกไม้
สมาชิกที่ให้กำลังใจ
 
Facebook
Twitter
Google

บันทึกอื่นๆ

ความเห็น

ไม่มีความเห็น
คุณต้องทำการเข้าระบบก่อนแสดงความเห็น