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
[email protected]
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 <[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 <[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 <[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
>
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
>
>
>
> --
> Mark R. Diggory
> @mire - 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]
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
>
>
>
>
> --
> Mark R. Diggory
> @mire - 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]
> 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
