Hi, put my +1 in column 3, thanks! Also, if you think of the config files as templates, then you can leave the immutable stuff in them, and just put the variable stuff in .properties files. Re: auth config, given that we have a new development tool in Vagrant-DSpace, it would be entirely possible to have a self-contained auth server setup (Shib, LDAP, etc.) and it would be nice to be able to use the same config "templates" while changing the server addresses based on your environment (vagrant, staging, production).
Perhaps it would be helpful if we all shared how we manage our various configurations? I know some people keep them in a private git repository, with each environment being a branch, and then check out this config folder and pass it in to Maven with a command line option (-Dconfig= I think, but I don't use it so I don't know). I rely solely on the -Denv= option myself. I think if we have a better idea of how we use the tools in practice, we'll better understand why we are proponents of the differing views of the build.properties file. --Hardy Sent from my iPad On Oct 2, 2013, at 5:14 PM, "Tim Donohue" <tdono...@duraspace.org> wrote: > Hi Developers & Committers, > > Recently there have been several JIRA tickets created that suggest new > configuration additions to our DSpace "build.properties" file. After > some informal discussion (amongst a few committers), we've started to > realize that we don't have a common definition on what configurations we > feel are most appropriate there. > > Here's a few suggestions on configs to add, which have already been > shown to be controversial (cause of our lack of definition around what > belongs in build.properties): > > https://jira.duraspace.org/browse/DS-1463 (Add Google Analytics to > build.properties) > https://jira.duraspace.org/browse/DS-1494 (Add some LDAP configs to > build.properties) > > There seems to be several (valid, yet competing) points of view on > build.properties: > > 1. "Minimum Set of Configs View" : build.properties is only meant to > contain the *minimum* set of configs that an institution must specify in > order to install DSpace and get it to be "minimally functional". After > that, all other configs should be tweaked directly in the appropriate > *.cfg files. > > 2. "Often Tweaked View" : build.properties is meant to contain the set > of configs that nearly all institutions (e.g. 80-90% of our DSpace > installations) are likely to want to tweak out-of-the-box almost > immediately. Anything that is a bit more unique/advanced should just be > tweaked directly in the appropriate *.cfg files. > > 3. "Different Environments View" : build.properties is meant to contain > configs which are often different for different environments > (development, testing, production). This eases the ability to swap out > these settings for your different local environments. Any settings which > are likely to be the same across several environments can just be kept > in the appropriate *.cfg files. > > There may be other points of views here that I haven't described. > > But, if you look closely, based on the POV, you may come up with > different answers to the JIRA tickets above. As a very basic example, > take the request to add Google Analytics settings to build.properties. > It may seem like a very valid request until you look at it from > different viewpoints. With the "Minimum Set of Configs View", GA may > not be applicable for build.properties (it isn't needed to get DSpace > basically running). But, with the "Often Tweaked View", it likely *is* > applicable (as Google Analytics seems to be widely used, and it might be > nice to tweak easily from build.properties). > > So, the question I'd like to pose is: Can we better define what > configurations should be "allowed" in build.properties? We obviously > don't want all configs in there, cause it turns into a massive config > file. But, we don't want it to be so small that it ceases to be > generally useful. (As a sidenote: it is possible for institutions to > obviously locally tweak their build.properties to add more configs.. we > may just want to better document that as a "workaround") > > Personally, I tend to lean towards the "Often Tweaked View" (though I > think both other views are completely valid options as well). I'd like > build.properties to include those configs which nearly everyone is going > to want to change out-of-the-box (no matter what their local environment > is). But, as has been pointed out to me, it may be hard to define what > that set of "often tweaked" configs is, as all institutions will have > their own views on what is most important to them. > > What do you think? What configurations do you feel belong / don't belong > in build.properties & why? > > - Tim > > -- > Tim Donohue > Technical Lead for DSpace & DSpaceDirect > DuraSpace.org | DSpace.org | DSpaceDirect.org > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
