Hello everyone, before I refer to the main topic of this thread, I just want to remind, that we still have a major issue with build.properties and its encoding: https://jira.duraspace.org/browse/DS-1528.
> > On Thu, Oct 3, 2013 at 11:20 AM, Anja Le Blanc > > <anja.lebl...@manchester.ac.uk> wrote: > >> For the content of the 'build.properties' file I would include all > >> the configs where I would object/feel uneasy to commit them into a > >> public git repository (user names, passwords, addresses to some servers, > ...). > >> Therefore I have only one file which is not in git. If I may recap we have four point of views: 1) Minimum Set of Configs, 2) Set of Often Tweaked Configs, 3) Mechanism for different Environments, 4) Set of Configs which contains security sensible information. What I'm afraid of is that build.properties might have the dimensions of dspace.cfg one day. It is so useful to me, because it is quite short but still contains the configs I need for a quick setup of a new DSpace installation. For every enhanced configuration I'm totally okay with editing some files under dspace/config/. I don't think that we should achieve that 80%-90% of all DSpace installations don't have to touch dspace.cfg, because then build.properties would just be dspace.cfg. But that's just my personal point of view. Perhaps we can bring up different mechanisms for all four needs? I have two ideas for it: As far as I remember the maven-filter-plugin, it is possible to have more than one properties file. So it would be possible to have one password.properties or sensitive.properties and our actual build.properties. The other idea is more a question: is it possible to have more than one config-directory and to tell mvn which one to use? If we could change the config directory mvn uses, we would get environments that may control every setting. No one would ask to add ldap settings to build properties because he wants to have different ldap environments. To elaborate this a little bit: I imagine a system property which tells mvn the location of the config directory. Mvn then does its magic (filtering and so on) and copies the specified directory to the target directory. We would neither have to change the mechanism the kernel uses to find the config directory nor the ant configuration. This could resolve the conflict between the need for environments and the Minimum set of Configs. I'm still not familiar with maven but perhaps someone who is can think about these ideas. Regards, Pascal ------------------------------------------------------------------------------ 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
