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

Reply via email to