Hi Mark,
Most of what we've changed in existing aspects has been very straight-forward.
I'm reluctant to add or customize essential information (contacts, feedback
forms, help pages, etc.) in the theme layer. I'd prefer this information to be
available should we need to change themes or revert to a default. Maybe
that's over-cautious.
What's been more difficult is working out how to manage our local code.
Threads like this & Mark W.' s point, in a previous reply, about pluggables
being developed outside the DSpace tree & configured in as needed, have been
helpful -- we're relatively new to DSpace & have limited experience with Java.
We haven't yet upgraded to 1.7 but I don't anticipate much grief, since our
mods are simple & can be added back in as/where needed, post-upgrade, to the
broken-out browse & search components.
Thanks again,
Jen Whitney
Electronic Text Centre, UNB Libraries
University of New Brunswick
[email protected]
On 2011-05-31, at 2:50 PM, Mark Diggory wrote:
> Jennifer,
>
> On Mon, May 30, 2011 at 8:17 AM, Jennifer Whitney <[email protected]> wrote:
> 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.
>
> Yes, this is fine. We do it as well (and as MarkW points out, this project
> can live outside the dspace/modules directory), we generally make that
> division when dealing with packaging more that one dspace instance off the
> same addon codebase, for instance in a consortia setting, where the same set
> of features need to be deployed on multiple dspaces, but there need to also
> be local customizations maintained to each instance (dspace/modules/...) as
> well.
>
> what would be interesting is to analyze how upgrades now impact your work.
> For instance, I can say we've been reworking parts of the ArtifactBrowser
> aspect to break out the Browse and Search Components and to make it possible
> to truly drop either of those two features in favor of turning on Discovery.
> Has this impacted your addon? Ideally, it shouldn't have.
>
> Likewise, I would be curious about what were the changes you sought out to do
> to ArtifactBrowser, knowing what those look like would inform us as to how to
> improve the parts of the codebase that can be replaced locally in the manner
> you are doing.
>
>
> 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).
>
> You wouldn't need to worry about it because you are releasing your
> customizations as your own addon to DSpace. Well done.
>
> Best,
> Mark
>
> --
> Mark R. Diggory
> @mire - www.atmire.com
> 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
> Esperantolaan 4 - Heverlee 3001 - Belgium
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
