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