Bit late to the party but I thought I'd share our approach for keeping XMLUI customizations separated from DSpace source. Recipe #1 has worked well for us, so far, when we've needed to modify 1.6.2:
https://wiki.duraspace.org/display/DSPACE/BuildCookbook
So, for example, we've cloned the vanilla ArtifactBrowser aspect in our project:
myrepo-xmlui/myrepo-xmlui-api/src/main/resources/aspects/MyArtifactBrowser
... and modified the sitemap.xmap, as needed, to point to classes in our projects, which mirror the structures of DSpace projects in the source release. We add dependencies on our projects to the relevant POMs, build & deploy as usual.
I think, since we're working in our own projects, that we'd avoid the kind of Maven repository contamination discussed below (something that didn't occur to me, previously).
Jen Whitney
Electronic Text Centre, UNB Libraries
University of New Brunswick
jwhitney@...
On 2011-05-27, at 7:52 PM, Mark Diggory 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 <pdietz84@...> 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 <mdiggory@...> wrote:
> Are you able to enable them in the xmlui.xconf at all?
>
> Mark
>
> On Fri, May 27, 2011 at 8:09 AM, Joseph <joseph.rhoads@...> 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
>
> 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
> _______________________________________________
> DSpace-tech mailing list
> DSpace-tech@...
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
>
>
>
> --
> Mark R. Diggory
> @mire - 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
> DSpace-tech@...
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
>
>
>
>
> --
> Mark R. Diggory
> @mire - 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
> DSpace-tech@...
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
|