I like to use Mercurial to track our local mods. http://www.selenic.com/mercurial/wiki/
There are some nice tools to support that: http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion I just do a simple setup though - keep a few copies of the code around. *. /dspace-pure/... - straight dspace-checkout *. /local-release/... - realease-ready code *. /work/... - work area When I have something in /work/ ready for release, then 'hg push' form work/ to local-release/ and run pre-release tests. When we're ready to pull in updates from dspace-repo, then svn update in dspace-pure/ hg pull the dspace-pure stuff into /work. Something like that. Long term dspace should consider moving to Mercurial for source control. Systems like Mercurial and Git (used by the Linux kernel team) make it easy to maintain local branches and repositories independent of the central "master" repository. I was disappointed to find that the dspace code base does not include a suite of JUnit regression tests - which complicates the update, merge process and forces add hock system-level testing. The current system's fragile design makes it difficult to add regression tests: *. use of classes instead of interfaces in the API makes it difficult to mock out subsystems *. extensive use of global (static) variables rather than dependency injection makes it difficult to isolate individual test cases. *. strong tie to database schema rather than object model with ORM mapping hidden away *. custom code rather than building on top of a J2EE platform (JBoss, Glassfish, Geronimo are all free) that provides database connection management, pluggable authentication, object-relational database mapping, logging, mail session management, transactions, etc. out of the box. I hope future versions of dspace include design changes, and introduce a suite of regression tests. Cheers, Reuben BTW - There are some great tools out there to help: http://code.google.com/p/google-guice/ http://www.junit.org/ http://www.easymock.org/ http://www.hibernate.org/ http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/tutorials/GeneralAcnOnly.html http://jboss.org/ http://geronimo.apache.org/ https://glassfish.dev.java.net/ http://java.sun.com/docs/books/effective/ >>> Diggory Mark <[email protected]> 2/3/2009 4:24 PM >>> Or to be more explicit you add the pom at {dspace-source}/dspace/modules/custom-api/pom.xml and modify the following with <module>custom-api</module> {dspace-source}/dspace/modules/pom.xml And add custom-api as a dependency in {dspace-source}/dspace/pom.xml Mark On Feb 3, 2009, at 2:14 PM, Diggory Mark wrote: > no > > On Feb 3, 2009, at 2:06 PM, Thornton, Susan M. (LARC-B702)[NCI > INFORMATION SYSTEMS] wrote: > >> Do I need to modify {dspace-source}/pom.xml ?? >> >> From: Diggory Mark [mailto:[email protected]] >> Sent: Tuesday, February 03, 2009 4:10 PM >> To: Thornton, Susan M. (LARC-B702)[NCI INFORMATION SYSTEMS] >> Cc: dspace-tech >> Subject: Re: [Dspace-tech] Local modifications to DSpace .java >> programs, in 1.5.1 >> >> Susan, >> >> The way to do it without altering the code in place requires >> creating a custom maven project within the dspace/modules/ >> directory, wiring it into the dspace/pom.xml and dspace/modules/ >> pom.xml so that it compiles into the build process. >> >> At this point, I'm seeing community member using both approaches, >> and I'm unsure which I would most recommend. But here's what I try >> to approach as a best practice. >> >> 1.) I don't like to alter code in place in dspace-api, dspace-xmlui >> or any of those projects unless I intend to contribute it into the >> next release of DSpace 1.5.x >> >> 2.) Keeping all those projects around lengthens the build process >> and if your not using all of them (dspace-sword, lni, etc) thats a >> lot of compile time for nothing. >> >> 3.) Once configured properly, your changes in dspace/modules/xxx >> will always be separate from the rest of the codebase, but you will >> still need to verify that upgrades don't break your customizations >> by comparing your code to the original. Something we continue to >> strive to get away from. >> >> So I would recommend the following steps: >> >> a.) create a dspace/modules/custom-api/pom.xml for your api >> changes. That looks something like the attached pom.xml >> > > ~~~~~~~~~~~~~ > Mark R. Diggory > http://purl.org/net/mdiggory/homepage > > > ~~~~~~~~~~~~~ Mark R. Diggory http://purl.org/net/mdiggory/homepage ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
