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. 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. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite.
pgpDdRnDJ5oTH.pgp
Description: PGP signature
------------------------------------------------------------------------- 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
