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 <pdiet...@gmail.com> 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 <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
>>
>>
>
--
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
