On Tue, Aug 02, 2011 at 12:15:48PM -0700, Mark Diggory wrote: > I'm not really getting what your suggesting, can you elaborate on why we > need a second config directory?
config/modules/X.cfg only gets read if code uses the
ConfigurationManager.getProperty("module","suffix") method. I was
hoping that I wouldn't have to go hack a bunch of code under test just
to make the tests continue to work in the "portable" framework. The
code under test could be using any supported method to configure
itself, could be dependent on distant methods that use any supported
methods to configure themselves, and the framework has no control over
that, nor should.
What I'm suggesting is that additional files be read into the
non-module Properties so that non-modularized code has access to their
content.
The particular problem at the moment is that
org.dspace.content.ItemTest expects the PluginManager and a certain
plugin to be set up in a certain way that isn't present in the model
dspace.cfg. I might need to hack up Item and/or PluginManager to make
certain that they're getting their configuration in the modular way.
Just to make three succeeding tests continue to succeed after changing
the test framework. (I haven't checked.)
I'm really wondering now why we did 'config/modules/modulename.cfg'
rather than 'config/dspace.d/anyname.cfg'.
> Would it make more sense to move authority control into a separate
> config/modules/authority.cfg?
If it were a module, and the configuration variables were all named
authority.*, then perhaps it would. But it isn't and they aren't, so
this doesn't work and may create confusion. It's a stew of
plugin.this, choices.that, authority.tOther. I'd need to write three
different "module" configuration files, and as noted above they might
not even be read without altering the code I want to test.
Have a look at the Authority Control Settings section of dspace.cfg to
see what I mean.
> Likewise.... write existing maven properties in effect to a file (could be
> used to write dspace.cfg and other module cfg.
>
> http://mojo.codehaus.org/properties-maven-plugin/index.html
I guess you're thinking:
1. properties:read-project-properties the model dspace.cfg;
2. add properties, change values as needed;
3. properties:write-project-properties
outputFile=target/testing/dspace/config/dspace.cfg
I guess that step 1 would have to be bound to the validate phase,
since project/properties (step 2) seems to happen in initialize.
I'm quite unhappy with the use I've already made of project properties
to get some plugins to do what I needed. Already I had one case where
a property leaked into a place where it wasn't wanted and I had to do
something more clever than smart to fix it. If only I could declare
properties confined to an execution of a plugin!
--
Mark H. Wood, Lead System Programmer [email protected]
Asking whether markets are efficient is like asking whether people are smart.
pgpKgXSMZrEHL.pgp
Description: PGP signature
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
