is there a reason why the language packs reside in
E.g. the sub-daily uses the Messages.properties in lib/dspace.jar (path
order) as for dsrun.
Thus if you change a tag which refers to org.dspace.eperson.Subscribe
and run ant update, the Messages.properties in lib/dspace.jar will not
be changed, because no java sources were changed and so the chaneges
made are not picked up.
Wouldn't it be better to have just one reference point (the install-dir)
From: Robert Tansley <roberttansley@go...> - 2007-03-27 14:06:27
On 27/03/07, Claudia J=FCrgen <Claudia.Juergen@...> wrote:
> is there a reason why the language packs reside in
> - [dspace-install]/config
> - dspace.war
> - lib/dspace.jar
Initially they were just in dspace.war. The Messages_xx.properties
need to be in the CLASSPATH to be picked up by the JSTL ResourceBundle
stuff. With a .war file, you don't get to choose what the CLASSPATH
is, you only get to put stuff in the .war. Then they got added to the
config/ directory so that other tools than the Web UI could use them.
I think they appear in dspace.jar as a side-effect of the way they are
included in the .war file (by copying into
There may be another way to fix this so that the language packs only
appear in config/. org.dspace.core.I18N is easy enough to change.
org.dspace.app.webui.servlet.LoadDSpaceConfig might need to perform
some trickery to ensure that [dspace-install]/config is checked for
those bundles. See: