OK, three ways to do this: 1) Have social-api depend on java/gadgets/conf/gadgets.properties to locate the container.js file 2) Have social-api hard code the location of shindig.containers.default in a Guice module. 3) Rename java/gadgets/conf/gadgets.properties to shindig/config/shindig.java.properties (or another suitable path, if you prefer)
Any preference? If you leave it to me I'll go with option 1 or option 3, depending on my mood. =) I'll go with option 1 if I'm feeling lazy, option 3 if I'm feeling disruptive. =) On Thu, Sep 25, 2008 at 2:36 PM, Ian Boston <[EMAIL PROTECTED]> wrote: > Ok that makes sense to me. > Ian > > On 25 Sep 2008, at 17:24, Kevin Brown wrote: > >> On Thu, Sep 25, 2008 at 11:17 PM, Ian Boston <[EMAIL PROTECTED]> wrote: >> >>> Having done a *bit* of work in social-api, I have no objections. >>> >>> I assume that this would not generate a dependency on gadgets from >>> social-api, but would generate a dependency on common (already there) and >>> a >>> load of properties in social-api. I think it would be quite confusing to >>> have config for social-api inside the gadgets tree ? >> >> >> The configuration is shared between the java and php code, it's not in the >> gadgets tree. It's in trunk/config. >> >> There is a properties file in the gadgets tree for system wide settings, >> but >> honestly most of those should be moved into container config as well (with >> some minor exceptions). >> >> >>> >>> >>> Ian >>> >>> >>> On 25 Sep 2008, at 16:21, Louis Ryan wrote: >>> >>> I don't have any major objections. The need is obvious, we can quibble >>>> >>>> over >>>> the details later. >>>> >>>> >>>> On Thu, Sep 25, 2008 at 1:19 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: >>>> >>>> On Thu, Sep 25, 2008 at 11:46 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: >>>>> >>>>>> Again, though, we could always re-invent per-container configuration >>>>>> for >>>>>> >>>>> the >>>>> >>>>>> umpteenth time that this discussion has come up, but we'll just come >>>>>> back >>>>>> >>>>> to >>>>> >>>>>> the same conclusion. We've proven time and time again that per >>>>>> container >>>>>> configuration is necessary because many implementations need to >>>>>> support >>>>>> >>>>> more >>>>> >>>>>> than one container in their deployment. >>>>>> >>>>> >>>>> Yep, I agree. I'd like to see somebody who works on the social-api >>>>> ack that this is the right thing to do before I check in a new >>>>> dependency. >>>>> >>>>> >>> > >
