[
https://jira.duraspace.org/browse/DS-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21662#comment-21662
]
Kevin Van de Velde commented on DS-989:
---------------------------------------
Comments for the Developers Meeting on Aug 10 2011
(http://irclogs.duraspace.org/index.php?date=2011-08-10):
[20:27] <tdonohue> KevinVdV, if I understand Ds-989 properly, this essentially
just means you could modify that <default.solr.server> *before* running mvn
package. Or you could modify Solr settings in both statistics.cfg and
discovery.cfg afterwards.
[20:27] <KevinVdV> Yes
[20:28] <KevinVdV> It would work like the dspace.dir property works
[20:28] <KevinVdV> & the solr setting is just one example
[20:29] <tdonohue> right. my point here is that *most users* won't want to go
into a pom.xml file to change settings. But, that's ok, cause they can still do
the same changes to *.cfg files that they've always done. This patch just lets
developers (or those who aren't scared of pom.xml changes) to centralize some
settings.
[20:29] <KevinVdV> Indeed that is the point
[20:30] <richardrodgers> If I understand, this is what ConfigurationManager
does for module config, but the CF does it dynamically (at property load time)
[20:30] <KevinVdV> Since the dspace.cfg already supports this I thought that
the module config files should also support it
[20:31] <tdonohue> this sounds OK to me. I'd have no objections to it
[20:32] <mhwood> I suspect that the model configuration files will be much more
heavily parameterized as we work toward installers and better testing and
things like that.
[20:32] <richardrodgers> I'm not sure - it might limit abilities already
present (as I mentioned)
[20:33] <tdonohue> richardrodgers: I'm not sure I understand what you said
about ConfigurationManager...I'm confused, or maybe I don't know what it does
exactly
[20:33] <richardrodgers> when a modular config property is requested, the file
is *lazy-loaded* and the ${key} are filtered
[20:34] <richardrodgers> it I understand this change, they will be
*pre-filtered* at build time
[20:34] <KevinVdV> It already "pre-filters" the dspace.cfg
[20:35] <richardrodgers> not dspace.cfg, but /modules/*.cfg
[20:35] <mhwood> The patch is selective, yes? If we want a token passed through
unaltered, we can do that?
[20:35] <KevinVdV> Yes
[20:35] <KevinVdV> Ofc
[20:35] <KevinVdV> The patch just "allows" people to use this
[20:36] <KevinVdV> Since you have to know a little bit about the pom's
[20:36] <tdonohue> right..so, currently this patch *does* pre-filter at build
time. But, the only thing it is pre-filtering is the solr.server (which is
already hardcoded currently in /modules/*.cfg files). So, it's not prefiltering
anything that requires lazy loading
[20:37] <tdonohue> or, richardrodgers, is it just the concept that someday this
could conflict with "lazy loading" of /modules/*.cfg that bothers you?
[20:38] * tdonohue notes we probably should move on soon...this seems like a
topic that we can bring offline
[20:38] <richardrodgers> I'm not sure I follow tdonohue - the assembly
descriptor does config/modules/** (all files)?
[20:39] <richardrodgers> but I agree - we should table this
[20:40] <tdonohue> oh, wait. yea, you might be right, richardrodgers (i do see
your point there). It'd be good to test this out and report back on the
comments of this issue
> Module directory maven property support
> ---------------------------------------
>
> Key: DS-989
> URL: https://jira.duraspace.org/browse/DS-989
> Project: DSpace
> Issue Type: Improvement
> Reporter: Kevin Van de Velde
> Priority: Major
> Attachments: Modules_directory_properties.patch
>
>
> Since it is now possible to use properties in the dspace.cfg file (dspace.dir
> = ${default.dspace.dir}) I have created a patch that also allows these
> properties in the {dspace.dir}/modules directory.
> The patch contains a working example for the solr server, once the following
> patch https://jira.duraspace.org/browse/DS-971 is committed this solr
> property can also be used in the discovery.cfg file. This way users will only
> have one place to put solr server property.
> The maven assembly plugin version had to updated for this to work since the
> beta version used in DSpace doesn't support a file filter for directories
> (http://jira.codehaus.org/browse/MASSEMBLY-154). The version now used is the
> latest stable on for the plugin (source:
> http://jira.codehaus.org/browse/MASSEMBLY).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it.
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
