On Tue, Aug 2, 2011 at 1:54 PM, Mark H. Wood <[email protected]> wrote:
> 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.)
>
The service manager configuration service, doesn't make a restriction on the
module/suffix. It uses the syntax
getProperty("authority.key");
if you were to, in the dspace.cfg, actually make the property be
"authority.key", it would be perceived in the same manner by the caller as
if you had created a file config/modules/authority.cfg which contained just
"key=foo"
So if I understand correctly, its just the ConfigurationManager that has
this problem.
> I'm really wondering now why we did 'config/modules/modulename.cfg'
> rather than 'config/dspace.d/anyname.cfg'.
>
TBH, the only reason I can think of was to stop overrides from happening
between config module properties files, which might have been a bit
paranoid.
> 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.
>
I'm all for changing it to make it be a module config and committing such
work.
> 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!
>
Write One ;-) seriously, they are really just java classes with a specific
interface, if we need to control our environment for testing better, maybe
we should write a custom testing plugin for maven that supports our testing
scenario. It might be easier to create the test environment via coding the
copying of resources directly in Java anyhow.
MarkD
--
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Esperantolaan 4 - Heverlee 3001 - Belgium
------------------------------------------------------------------------------
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
