That all sounds right to me. Maybe we don't need a meeting on this - just a commitment to make it better in the future. I created a new JIRA (DEV-969) for this:
JIRA - https://jira.terracotta.org/jira/browse/DEV-969 -------------------------------------------------------- Based on tc-dev thread (started by Geert, commented on by Tim, Taylor, etc), we should make the definition and use of tc.properties props more consistent and centralized in the code. Specifically, we should: 1) Move prop definitions into a central source file so we know where to look 2) Make key space follow some convention (none followed now) 3) Minimize or eliminate use of tc.properties by config modules Notes from Tim: - tc.config and tc.install-root should remain as system properties and should NOT be in tc.properties - they are needed for bootstrapping and are two widely used - due to #3 above, the source file we define tc props in should probably not be in a -api project (unless that's the only option due to other dependencies) -------------------------------------------------------- and the the issue review board can schedule as desired... ----- Original Message ----- From: "Taylor Gautier" <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, September 25, 2007 1:33:54 PM (GMT-0600) America/Chicago Subject: Re: [tc-dev] TC system properties Tim I think you are on the right track here. Consistent: good. External: bad. tc.properties are a way to contain the inevitable "hidden" settings that creep into any system. For that reason, they are explicitly not documented, because documentation would necessarily freeze them and developers would naturally move away for things that are not quite done in the sense of being mature and documented features. So making these things external and published and consumable is not a good idea, imo. Making them consistent is a good idea, so we "contain the mess(iness)" so to speak. Tim Eck wrote: Apologies up front if I create a giant can of worms here, but left uncontrolled this kind of stuff usually gets out of control. Note: this isn't related to decision of where the API goes -- that is a different topic. I'm personally not a big fan of proliferating the use of system properties in the code base (even if they get consolidated to some central class, or set of constants). We created "tc.properties" specifically to avoid using raw system properties. Conceptually there isn't a huge difference between tc.props and regular system properties, it's just a way to introduce one layer of indirection (useful for testing, isolation, different sourcing methods, etc). That said there are at two things that should really remain system properties (tc.config and tc.install-root). Why? They are required for bootstrapping the client and are firmly cemented in the wild IMO. Let me be the first to say that "tc.properties" could use some more attention. Off the top of my head, these are some things could use some work: - The key space for tc.props is completely ad-hoc right now -- Something akin to a constants interface with safety checks built in could fix that - I don't think tc.props are well suited for config modules - The implementation uses a static under the covers So the question I'm really throwing out there is -- Can we unilaterally use tc.props in place of system properties? -----Original Message----- From: [EMAIL PROTECTED] [mailto:tc-dev- [EMAIL PROTECTED] On Behalf Of Geert Bevin Sent: Tuesday, September 25, 2007 7:47 AM To: [email protected] Subject: [tc-dev] TC system properties Hi, I was just reading through the source code and I noticed that the system properties that are supported by Terracotta are really scattered around the code base. Wouldn't it be good to create a TerracottaProperties interface in the 'common' project that consolidates all these property names as constants? Is 'common' the correct project for this? Do all the other DSO projects depend on it? Thanks, Geert _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
