On Sep 25, 2008, at 12:53 PM, Mark H. Wood wrote: > Has anyone had time for further thought about this? > > Quick recap: > > o I got tired of editing scores of lines in message catalogs to > replace "DSpace" with the name of one of our four production > DSpaces wherever it refers to the site and not the product. > > o I coded up a solution: runtime configuration property substitution > in the message texts. > > o There was some quite reasonable objection to substituting static > data every time a given message is inserted into a page, and a > counterproposal to have Maven fix up the messages. > > o I objected to having Maven know anything out of dspace.cfg and > suggested that the install step (i.e. build.xml) might be the best > place, *except* that build-time bakes Messages.properties into > dspace.jar for the commandline utilities. Suggested moving > Messages.properties back out of the .jar.
Here are my issues, Messages.properties/xml are traditionally reserved for externalizing static string of text that the application uses so that they can be localized to different languages, transforming them on the fly defeats this process. My recommendation is for us to look at the externalized strings and consider rewording them or parameterizing them so that you do not have to transform the file to "insert" you repository name into the output. http://java.sun.com/developer/JDCTechTips/2003/tt0819.html This would completely alleviate the issue and the messages can stay in the Jars and not need to be touch by you directly. Likewise, we worked hard in 1.5.0 to get it so that one can insert ons own customized messages-foo.xml catalog along side the default, this allowing you to make your customizations in a separate file... we should work to replicate this functionality in the JSPUI and better document it in the XMLUI. > > o Silence.... > > To bump the discussion along: I've just recalled that Zip archives > (and thus Jar archives) can be updated, so build.xml could replace > Messages.properties in dspace.jar. Ant's zip task can do that. I think thats very bad form as it alters what we are trying to Isolate you from altering, the DSpace API. Good topic, -Mark ~~~~~~~~~~~~~ Mark R. Diggory - DSpace Developer and Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology Home Page: http://purl.org/net/mdiggory/homepage ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
