I am not certain if this helps but here goes,
If you are talking about the PersonService, ActivityService in the
social-ap
etc then SHINDIG-203 and SHINDIG-204 might help
If you are not, then I have misread, sorry, ignore the rest.
203 abstracts the interface between the social-api implementation and
the sample container core (for the social part) so they could be
separated. The patch was good a while back but would probably need a
refresh.
204 provides a DB based impl of PersonService (for most of the major
relational db's), that although is probably no real use as it stands,
is slightly closer to a read/write imple. This is not fully tested or
complete, but the datamodel has some reasonably extensive unit tests
against it.
Having separated out with 203, it would not be too hard to put the
samplecontainer and db impl of the social api services into a
separate jar that would be guice constructed in the server
web.xml..... if that makes any sense. As always, having suggested
something.... if its what you want then I would be happy to help on
all or part of it.
Ian
On 13 May 2008, at 09:31, Kevin Brown wrote:
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
