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 <mdigg...@atmire.com> 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.rho...@gmail.com> 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@lists.sourceforge.net
>> 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
> DSpace-tech@lists.sourceforge.net
> 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
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Reply via email to