On Tue, May 13, 2008 at 12:56 AM, Cassie <[EMAIL PROTECTED]> wrote: > For the java side, if we could somehow move the samplecontainer java > code and the serving of the javascript folder out into the server pom > then that would be what you wanted, right Kevin?
No, I was actually just thinking that it doesn't make a lot of sense to have a completely throwaway implementation packed into the main code base. On the other hand, it's not clear to me that there's any "good" way to provide default implementations of the data handlers that would actually be useful. That was really just an aside though. The main issue was resolved by replacing the dependency on RemoteContentFetcher on a simpler dependency directly on the commons http client. > > > (not that I know how to do that, but we could file a bug against > ourselves and fix it later.) > > I actually don't think this is a super urgent thing to fix. The > samplecontainer java code is pretty much stagnant and won't be getting > any new dependencies. The benefits of having a container that actually > does something by default pretty much outweigh any drawbacks in my > mind. And if the js code gets more complex I don't think that will > bother anybody either.. its just js and easy to exclude from real > deployments. > > - Cassie > > > On Tue, May 13, 2008 at 8:29 AM, Santiago Gala <[EMAIL PROTECTED]> > wrote: > > On Tue, May 13, 2008 at 5:22 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: > >> On Mon, May 12, 2008 at 3:57 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > >> > I was actually just going to suggest that they simply be separate > artifacts, > >> > not anything as involved as the "sub-projects" under jakarta and > the like. > >> > >> +1. The gadget container and gadget rendering server are joined at > >> the hip, it makes sense to have them both under the shindig umbrella. > >> > > > > +1 with having them as separate artifacts. > > > > Re: the comparison with jakarta, I was not implying moving code out of > > shindig, just explaining why there is a cultural bias against making > > too many separate departments in the same project. If subprojects are > > created, they would be kept here. > > > > The use case of Chris is closer to give some trouble in this regard: > > Developing a full fledged container, with "concrete" implementation of > > the APIs, is beginning to have a non-100% overlap with the shindig > > charter. Further, a number of people involved in shindig are > > maintaining private (or at least "uninteresting" for outsiders) > > interfaces to their systems, so they would not likely be interested at > > all in having a sample implementation, ... > > > > I guess that, for the moment, the approach that Chris has taken, i.e. > > open an outside project and see who joins, is the best. We can > > consider getting the code back into Apache as needed in the near > > future. > > > > Regards > > Santiago > > >
