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?
(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 >
