Hi, Joseph, as you can see opinions differ on the best practice. I can tell you that, for a long time, I tried to do theme development using Maven overlays. However, I ran into trouble many times, when searching for a solution (or asking for help, myself) many answers from developers will include paths and code snippets that will not work within, or may be difficult to adapt to the maven overlay method of working. I'm a web developer, and am very comfortable around version control systems.
If you're working with an XMLUI theme, it's very convenient to be working just a few folders away from the templates you are overriding. Sorry to muddy the waters a bit more. --Hardy Sent from my iPad On May 27, 2011, at 5:53 PM, "Mark Diggory" <[email protected]<mailto:[email protected]>> wrote: Joseph, I will say there are dramatically differing opinions on this in the community. While I see the benefits that Peter points out, as he says it is an approach that requires you to use tools that will aid in tracking and merging your modifications. Peter is creating much code for contribution back to DSpace, and in that case his approach does make sense. But this is not how I advise the enduser application developer customizing DSpace for their organization do things. (Sorry Peter, you rock!) Primary concerns with modifying the code directly: 1.) Known: You need to merge all your changes, you need to know git, you need to drag around and manage the entire dspace codebase. 2.) Not so well known: when you alter a class inside dspace-api and you build and package, you create "variants" of dspace-api-N.N.N.jar, This can get more confusing and unpredictable when you try to build projects that are not in the same maven reactor build plan as your altered build, and even worse, if you then run mvn install thinking to up that jar into your local maven repository, you then dirty all your unrelated builds. To take it a step further anyone who might "publish/deploy" these derivatives in a manner that they end up in a public maven repository could serious "soil" other peoples maven builds if they depend on that repository. I believe it will get the average application developer (who is not working specifically to contribute into dspace, but to meet their organizations deployment needs) into trouble. With this in mind, I do believe that it is wiser to keep your changes out of the dspace-xxx projects unless you plan to contribute them back to the community for inclusion in the next/future release. In you case, you are altering creating themes for a local deployment, and I advise that it is best to keep them in your dspace/modules/xmlui/scr/main/webapp/themes directory and not upstream in the dspace-xmlui-webapp project. Mark On Fri, May 27, 2011 at 3:19 PM, Peter Dietz <<mailto:[email protected]>[email protected]<mailto:[email protected]>> wrote: Hi Joseph, "Best practices" recommendations will tell you to put all of your modifications into [source]/dspace/modules, however, that isn't the most efficient way to do things (for me atleast). The straw that broke the camels back for me on the matter, was when I was customizing dspace-api (something that average user shouldn't be doing), and was getting inconsistent results with using modules/custom-api/src/main/whatever. I found myself uncompiling the jars in /dspace/lib and /dspace/webapps/xmlui/WEB-INF/lib to see if my customizations were making it in to both the command line launcher and the UI. Long story short, I didn't find enough benefits of using the modules overlay to justify all the extra work to support keeping code separate. When I do upgrades, I have both Git, and Meld to compare differences that have been made, and I get to compare my customizations right with normal code. So management of changes is hardly an issue for me. With 1.7.2 being released, among other things, it fixes a file CommunityRecentSubmissions.java (xmlui aspect). If you had customized that locally on 1.7.1, and moved it to modules, and then just replaced everything non-modules with the 1.7.2 version, your customization (which doesn't have the new fixes) will override the new changes, and your upgrade will still have the bug. If you instead have a customized CommunityRecentSubmissions in dspace-xmlui-api, then when you diff/merge/copy-in the 1.7.2 files you'll get a notification that Recent.local and Recent.remote are different, and you'll get a chance to hand-merge them. Another benefit of keeping modifications directly in the tree as opposed to modules, is that if I want to create a patch based on what I have, or accept someone else's patch, I don't have to fiddle with it just to make it happen. As we consider moving to asynch releases, or for users who use the release distribution, or just "keep it simple" then maybe the modules overlay will stay the preferred way. Peter Dietz On Fri, May 27, 2011 at 4:11 PM, Mark Diggory <<mailto:[email protected]>[email protected]<mailto:[email protected]>> wrote: Are you able to enable them in the xmlui.xconf at all? Mark On Fri, May 27, 2011 at 8:09 AM, Joseph <<mailto:[email protected]>[email protected]<mailto:[email protected]>> wrote: Dear Dspace-Tech, This is more of a general best-practices question. Where should new themes we develop live? 1) "dspace-source/dspace-xmlui/dspace-xmlui-webapp/src/main/webbapp/themes/" 2)"dspace-source/dspace/modules/xmlui/src/main/themes/" The first is what is suggested on the Manikin Theme Tutorial wiki <https://wiki.duraspace.org/display/DSPACE/Manakin+theme+tutorial>https://wiki.duraspace.org/display/DSPACE/Manakin+theme+tutorial I know most things we develop on our own should probably live in the modules directory, that way it's fairly easy to transfer them to a new DSpace installation, or an upgrade. Specifically: I ran across a problem when using option (2) where, and I'm trying to dynamically switch to a development theme I have in a modules directory. Using http://<manakin-url>/search?themepath=NewTheme/ I'm able to switch to all of the preinstalled themes (Classic, Reference, Kubrick, and Mirage) but I'm not able to switch to any that I've created myself. I get: "java.lang.IllegalArgumentException: The user specified theme path, "NewTheme/", may be an exploit attempt. To use this feature please limit your theme paths to only letters (a-Z), numbers(0-9), dashes(-), underscores (_), and trailing forward slashes (/)." Any ideas what might be going wrong? Thank You, Joseph ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. <http://p.sf.net/sfu/quest-d2dcopy1>http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ DSpace-tech mailing list <mailto:[email protected]>[email protected]<mailto:[email protected]> <https://lists.sourceforge.net/lists/listinfo/dspace-tech>https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Mark R. Diggory @mire - <http://www.atmire.com/> www.atmire.com<http://www.atmire.com> 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Esperantolaan 4 - Heverlee 3001 - Belgium ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. <http://p.sf.net/sfu/quest-d2dcopy1>http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ DSpace-tech mailing list <mailto:[email protected]>[email protected]<mailto:[email protected]> <https://lists.sourceforge.net/lists/listinfo/dspace-tech>https://lists.sourceforge.net/lists/listinfo/dspace-tech -- Mark R. Diggory @mire - <http://www.atmire.com/> www.atmire.com<http://www.atmire.com> 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Esperantolaan 4 - Heverlee 3001 - Belgium ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ DSpace-tech mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
