On Fri, Apr 18, 2008 at 4:56 AM, Ian Boston <[EMAIL PROTECTED]> wrote:
> Cassie's approach is perfectly valid. > > Some clarification of my thinking which is focused on the > 'users/implementors' of the software outputs of Shindig. > > The only reason for the resources was that, when you do a release of > Shindig. You will put things into repo2.apache.org as artifacts. > > Putting the server.war in there will make it harder for an implementor to > build a custom deployment using their own pom with overlays, since the > filtering will be complex. > > Putting the resource overlays in should make it easier to build one, or > both of the services. > > As I said Cassie's approach is valid, probably better for the project > developers, but might be harder for someone using shindig as a dependency > from the maven repo. (always, assuming they work that way) Someone pulling in shindig from maven would be pulling in the appropriate jars (gadget rendering, social api, or both). The sample files really only belong in the sample web app, because that's all they are -- samples. The resources required for actually running (feature.xml files, properties files, etc.) are pretty closely tied to a specific jar, and as such should be bundled as ordinary resources within those artifacts. > > Ian > > > > > On 18 Apr 2008, at 09:57, Cassie wrote: > > > So I got something working on my box which is similar to yours Ian but > > eliminates the *-resources projects. In order to do this I just directly > > had > > the java/server thing directly declare the conf and javascript files and > > what not to be resources. > > > > I personally didn't think this was so bad because its like how the > > web.xml > > thing works, everything is just sorta duplicated. I also like this > > because I > > could still run java/gadgets by itself and have it pull down the example > > files. (as opposed to having to build the resources directory as well > > and > > run them together - although perhaps i just screwed that up) > > > > So... what do the people listening to this think: > > 1. Ian's patch which pulls out two overlay wars gadgets-resources and > > social-resources to specify which resources each server needs > > 2. A slightly modified version which takes the stuff in Ian's > > *-resources > > poms and drops it into the server/pom. This basically hardcodes the > > resources the java/server pom needs while removing the two overlay wars. > > > > Thanks. > > > > - Cassie > > > > ps - Kevin - I didn't understand what you said at all > > > > On Fri, Apr 18, 2008 at 1:34 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > > I don't think the resource files are necessary to achieve this. There's > > > no > > > reason to have the web resources published statically anywhere but in > > > the > > > webapp (the war), so therefore that's the only thing that needs to > > > worry > > > about it. The other resources are common to all language > > > implementations, > > > and should be pulled in by the appropriate artifacts using relative > > > paths > > > as > > > they are currently. > > > > > > On Thu, Apr 17, 2008 at 2:00 PM, Ian Boston <[EMAIL PROTECTED]> wrote: > > > > > > Cassie, > > > > > > > > Sorry for the delay in responding, been in local project > > > > planing/panic > > > > mode today :) > > > > > > > > social-api and gadgets pack into jars, that end up as dependencies > > > > in > > > > WEB-INF/lib when the final war is built. The things that need to be > > > > on > > > > > > > the > > > > > > > classpath are in those files. > > > > > > > > social-api-resources and gadgets-resources contain the files we want > > > > exposed in the webapp, so they need to be wars (or perhaps zips). > > > > When > > > > > > > they > > > > > > > are pulled in in the build of the final war they are overlayed. > > > > > > > > Unfortunately this generates lots of artifacts and poms, 6 (3 jars, > > > > 2 > > > > overlay wars, 1 target war). > > > > > > > > We cant put the contents of the overlay wars into the jars, because > > > > they > > > > a) are not part of the classpath b) probably dont make sense being > > > > overlayed. > > > > > > > > We could put both resource builds into the target war build > > > > (server.war), > > > > but then they would not end up in the maven repo, and so it would > > > > not be > > > > possible for 3rd parties to generate a war from the maven repo. > > > > > > > > We could merge the overlay wars into 1 war, but then we would end up > > > > with > > > > all the social files in a gadget server (and visa versa) > > > > > > > > So..... I think the 3 jars, 2 overlays and one target offers > > > > flexibility, > > > > while keeping the build automated..... but I am always open to > > > > > > > suggestions. > > > > > > > > > > > > > > > The conf directory in social-api and gadgets contains the Guice > > > > > > > properties > > > > > > > file for each respective Module (eg gadgets.properties and > > > > social.properties), that needs to be in the classpath, and hence is > > > > > > > packed > > > > > > > with the Jar. I think I am right in saying that if someone wanted to > > > > > > > provide > > > > > > > their own set of properties, a file ending up in WEB-INF/classes > > > > would > > > > > > > take > > > > > > > precedence when the classloader performs the resolution. > > > > > > > > You may be using a name other than social.properites. > > > > > > > > I hope that makes sense, if it doesn't, its almost certainly my poor > > > > explanation, so please ask questions. > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > On 17 Apr 2008, at 16:07, Cassie wrote: > > > > > > > > Alright, Ian I grabbed most of the easy stuff in your patch and I > > > > > think > > > > > I'm > > > > > getting a better idea of what the rest of it does. Just one quick > > > > > question > > > > > though - do we really need to separate out the *-resources > > > > > projects > > > > > > > > > from > > > > > > > the > > > > > java/gadgets and java/social-api poms? If we add in everything in > > > > > the > > > > > patch > > > > > we will end up with 6 sub directories, and 8 total pom files :( > > > > > If we > > > > > can > > > > > package the resources up with the servers themselves then at least > > > > > we > > > > > are > > > > > back down to 4 modules. > > > > > > > > > > Aside from that it looks good although I don't understand what the > > > > > new > > > > > conf > > > > > directory is in the social and gadgets pom files: > > > > > + <resources> > > > > > + <resource> > > > > > + <directory>conf</directory> > > > > > + </resource> > > > > > + </resources> > > > > > > > > > > Thanks for bearing with my naiveté! > > > > > > > > > > - Cassie > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 16, 2008 at 7:00 PM, Ian Boston <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Ok, > > > > > > > > > > > I've updated the patch on 200, > > > > > > > > > > > > > > > > > > do you want me to pull your patch in locally, merge with my one > > > > > > and > > > > > > then > > > > > > update my patch on 200. > > > > > > > > > > > > or > > > > > > > > > > > > do you want to take the patch I have put on 200 > > > > > > (serverbuild2.patch) > > > > > > and > > > > > > merge with yours. > > > > > > > > > > > > If you take SocialApiGuiceModule, then I have no mv or cp > > > > > > operations, > > > > > > so I > > > > > > might be easier that way round as you have commit. > > > > > > > > > > > > I'm Ok either way.... except its getting close to kids bedtime > > > > > > GMT, > > > > > > > > > > > so > > > > > > > I > > > > > > will soon go offline for a few hours. > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 16 Apr 2008, at 17:21, Cassie wrote: > > > > > > > > > > > > Yeah, I saw these too and fixed them in the patch I attached to > > > > > > > > > > > > > SHINDIG-200. > > > > > > > > > > > > > > I ended up making a new SocialApiGuiceModule for the social > > > > > > > > > > > > > specific > > > > > > > guice > > > > > > > stuff and moving a bunch of files into common. > > > > > > > > > > > > > > - Cassie > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 16, 2008 at 5:49 PM, Ian Boston <[EMAIL PROTECTED]> > > > > > > > wrote: > > > > > > > > > > > > > > I am finding some build problems, Ok to fix in my patch ? > > > > > > > > > > > > > > > > > > > > > > 1. The shared dependency of GadgetDataHandler in both > > > > > > > > gasdget and > > > > > > > > social > > > > > > > > 2. The DefaultGuiceModule that needs to be split. > > > > > > > > > > > > > > > > If ok I am going to move to common. I will keep a list of > > > > > > > > svn > > > > > > > > commands. > > > > > > > > > > > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 16 Apr 2008, at 12:30, Cassie wrote: > > > > > > > > > > > > > > > > Alright Ian - my change is in, so let's make yours work. > > > > > > > > > > > > > > > > > > > > > > > > > Should we pull out a java/common directory that both > > > > > > > > > gadgets > > > > > > > > > > > > > > > > > and > > > > > > > the > > > > > > > > > social-api poms depend on? We could check in an empty > > > > > > > > > directory > > > > > > > > > for > > > > > > > > > now just as a place holder so that we can get the > > > > > > > > > structure > > > > > > > > > right. > > > > > > > > > > > > > > > > > > As for the resources: > > > > > > > > > - features = gadgets server > > > > > > > > > - config = gadgets server > > > > > > > > > - javascript = a joint server which has both gadgets and > > > > > > > > > social-api > > > > > > > > > running? > > > > > > > > > > > > > > > > > > I think that is close to what we may want... > > > > > > > > > > > > > > > > > > - Cassie > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston < > > > > > > > > > [EMAIL PROTECTED]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Done > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/SHINDIG-200 > > > > > > > > > > > > > > > > > > > > Its not complete since it needs the changes from 199, > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > also > > > > > > > needs > > > > > > > > > > clarification on which resources are part of which > > > > > > > > > > server > > > > > > > > > > > > > > > > > > > (the > > > > > > > javascript > > > > > > > > > > files etc) > > > > > > > > > > > > > > > > > > > > It will run using jetty:run, but the only drawback is > > > > > > > > > > that > > > > > > > > > > > > > > > > > > > now > > > > > > > that the > > > > > > > > > > wars > > > > > > > > > > are overlaid, it takes a mvn compile (in a separate > > > > > > > > > > window) > > > > > > > > > > > > > > > > > > > to > > > > > > > get the > > > > > > > > > > files > > > > > > > > > > into a place where jetty will notice they have changed. > > > > > > > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 16 Apr 2008, at 01:51, David Primmer wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sound good. Looking forward to the patch. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown < > > > > > > > > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > +1 -- I like this a lot, even if it is slightly more > > > > > > > > > > > > > > > > > > > > > > > complex. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 15, 2008 at 5:13 PM, Ian Boston < > > > > > > > > > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Looking at the patch and just having updated from > > > > > > > > > > > > svn, I > > > > > > > > > > > > think this > > > > > > > > > > > > > > > > > > > > > > > > means > > > > > > > > > > > > > that > > > > > > > > > > > > > in addition to the patch Cassie is working on.... > > > > > > > > > > > > > > > > > > > > > > > > > > java/social-api becomes a jar > > > > > > > > > > > > > java/gadget becomes a jar > > > > > > > > > > > > > > > > > > > > > > > > > > --------- > > > > > > > > > > > > > There is a new project to build a overlay war from > > > > > > > > > > > > > features/** > > > > > > > > > > > > > javascript/** config/** , > > > > > > > > > > > > > perhapse split into 2, one for gadgets and one for > > > > > > > > > > > > > social-api (not > > > > > > > > > > > > > certain > > > > > > > > > > > > > about the split) > > > > > > > > > > > > > eg > > > > > > > > > > > > > > > > > > > > > > > > > > java/gadget-resources > > > > > > > > > > > > > java/social-api-resources > > > > > > > > > > > > > > > > > > > > > > > > > > These just contain a pom.xml that builds the > > > > > > > > > > > > > overlay. > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------- > > > > > > > > > > > > > Then there is a new webapp > > > > > > > > > > > > > java/server > > > > > > > > > > > > > > > > > > > > > > > > > > That contains src/main/webapp/WEB-INF/web.xml > > > > > > > > > > > > > > > > > > > > > > > > > > that unpacks the overlay wars, pulls in the jars > > > > > > > > > > > > > and > > > > > > > > > > > > > packages as a > > > > > > > > > > > > > war... > > > > > > > > > > > > > for running in jetty. > > > > > > > > > > > > > > > > > > > > > > > > > > This would not enforce boundaries between > > > > > > > > > > > > > social-api > > > > > > > > > > > > > > > > > > > > > > > > > and > > > > > > > gadget, but > > > > > > > > > > > > > would > > > > > > > > > > > > > enable both to run, and for others to construct a > > > > > > > > > > > > > target. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Perhaps thats too complex and there could be some > > > > > > > > > > > > > simplification.... > > > > > > > > > > > > > I > > > > > > > > > > > > > would be happy to generate a patch once Cassie is > > > > > > > > > > > > > done.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One other thing. I have found that the maven > > > > > > > > > > > > > plugins > > > > > > > > > > > > > that build > > > > > > > > > > > > > sites > > > > > > > > > > > > > (less important) and perform releases(more > > > > > > > > > > > > > important) > > > > > > > > > > > > > are picky > > > > > > > > > > > > > about > > > > > > > > > > > > > the > > > > > > > > > > > > > relationship between the directory name, the > > > > > > > > > > > > > artifact > > > > > > > > > > > > > ID, how the > > > > > > > > > > > > > group > > > > > > > > > > > > > ID > > > > > > > > > > > > > changes as the directory structure gets deeper. > > > > > > > > > > > > > > > > > > > > > > > > > > If you want to use these plugins in multiproject > > > > > > > > > > > > > mode, > > > > > > > > > > > > > then it > > > > > > > > > > > > > probably > > > > > > > > > > > > > worth trying them now... just to make certain that > > > > > > > > > > > > > they > > > > > > > > > > > > > do work. If > > > > > > > > > > > > > the > > > > > > > > > > > > > entire build is maven2 based, the the release > > > > > > > > > > > > > plugin is > > > > > > > > > > > > > well worth > > > > > > > > > > > > > the > > > > > > > > > > > > > hassle Changing artifact names and structure later > > > > > > > > > > > > > an > > > > > > > > > > > > > > > > > > > > > > > > > be > > > > > > > a complete > > > > > > > > > > > > > pain, > > > > > > > > > > > > > see > > > > > > > > > > > > > > > > > > > > > > > > > https://source.sakaiproject.org/svn//kernel/trunk/tosee > > > > > > > > > > > > what > > > > > > > I > > > > > > > > > > > > > mean. > > > > > > > > > > > > > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 16 Apr 2008, at 00:40, Kevin Brown wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 15, 2008 at 3:14 PM, Ian Boston < > > > > > > > > > > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One way might be... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > add a webapp project that takes a jar from > > > > > > > > > > > > > > gadgets > > > > > > > > > > > > > > > > > > > > > > > > > > > > > and a jar from > > > > > > > > > > > > > > > social > > > > > > > > > > > > > > > api and a jar from common and builds the war. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > That's what I'm in favor of doing. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It might also overlay wars or zips containing > > > > > > > > > > > > > > all > > > > > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > javascript > > > > > > > > > > > > > > html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > > > > > > > > > > css files.. so that in the war project there > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > > > > > > > > > > > > just > > > > > > > the web.xml > > > > > > > > > > > > > > > thatis used > > > > > > > > > > > > > > > for a sample deployment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > These would belong in there as well, as > > > > > > > > > > > > > > > resources. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Then with the jetty target, run that war. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For those who want to construct their own > > > > > > > > > > > > > > > webapp > > > > > > > > > > > > > > > > > > > > > > > > > > > > > and > > > > > > > perhaps > > > > > > > > > > > > > > > customize > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > injection of the service layer, they can pull > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > gadgets jar, the > > > > > > > > > > > > > > > social-api jar and the javascript zip/jar/war > > > > > > > > > > > > > > > from > > > > > > > > > > > > > > > the maven repo > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > merge > > > > > > > > > > > > > > > with their own webapp project (with a > > > > > > > > > > > > > > > customized > > > > > > > > > > > > > > > web.xml, service > > > > > > > > > > > > > > > implementation jar and guice service module) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And that's exactly what I've been asking for. > > > > > > > > > > > > > > > It's > > > > > > > > > > > > > > > > > > > > > > > > > > > > > exactly what I > > > > > > > > > > > > > > want > > > > > > > > > > > > > > to do > > > > > > > > > > > > > > for our deployments at google, and I'm sure it's > > > > > > > > > > > > > > a > > > > > > > > > > > > > > model that other > > > > > > > > > > > > > > people > > > > > > > > > > > > > > would like as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 15 Apr 2008, at 17:08, Cassie wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okay, so I think we are mostly in agreement > > > > > > > > > > > > > > > that > > > > > > > > > > > > > > > the setup of the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Shindig java code needs to evolve towards > > > > > > > > > > > > > > > > > > > > > > > > > > > > > something > > > > > > > like this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > java/gadgets/* -- gadget rendering code > > > > > > > > > > > > > > > > java/social-api/* -- code for serving social > > > > > > > > > > > > > > > > data > > > > > > > > > > > > > > > > (eventually all > > > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > the restful wire format) > > > > > > > > > > > > > > > > java/common/* -- all the rest of the common > > > > > > > > > > > > > > > > code > > > > > > > > > > > > > > > > shared by > > > > > > > > > > > > > > > > everybody > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In order to start going this direction I > > > > > > > > > > > > > > > > have a > > > > > > > > > > > > > > > > patch that does > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > following: > > > > > > > > > > > > > > > > 1. Moves the java social code and javatests > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > social > > > > > > > code into the > > > > > > > > > > > > > > > > java/social-api component (out of > > > > > > > > > > > > > > > > java/gadgets) > > > > > > > > > > > > > > > > 2. Moves the socialdata servlet registration > > > > > > > > > > > > > > > > from > > > > > > > > > > > > > > > > the gadgets > > > > > > > > > > > > > > > > web.xml > > > > > > > > > > > > > > > > to the social-api web.xml > > > > > > > > > > > > > > > > 3. Moves the pom/parent/pom.xml into > > > > > > > > > > > > > > > > java/pom.xml > > > > > > > > > > > > > > > > This is > > > > > > > > > > > > > > > > necessary > > > > > > > > > > > > > > > > for making a multi-module project (See > > > > > > > > > > > > > > > > things > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > like > > > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://www.javaworld.com/javaworld/jw-05-2006/jw-0529- > > > > > > > maven.html > > > > > > > > > > > > > > > > ?page=2 > > > > > > > > > > > > > > > > for more info) We need a multi-module > > > > > > > > > > > > > > > > project > > > > > > > > > > > > > > > > because currently > > > > > > > > > > > > > > > > social-api depends on gadgets (and > > > > > > > > > > > > > > > > eventually > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > they > > > > > > > will both > > > > > > > > > > > > > > > > depend > > > > > > > > > > > > > > > > on > > > > > > > > > > > > > > > > common) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Using this ridiculously large patch you can > > > > > > > > > > > > > > > > do > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > following: > > > > > > > > > > > > > > > > - use mvn jetty:run-war in java/gadgets like > > > > > > > > > > > > > > > > usual. however, the > > > > > > > > > > > > > > > > socialdata servlet won't be there and so all > > > > > > > > > > > > > > > > social stuff will > > > > > > > > > > > > > > > > break > > > > > > > > > > > > > > > > (including the samplecontainer - we will > > > > > > > > > > > > > > > > have to > > > > > > > > > > > > > > > > fix this later) > > > > > > > > > > > > > > > > - use mvn compile in java/ to compile all > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > gadgets stuff and > > > > > > > > > > > > > > > > all > > > > > > > > > > > > > > > > the social-api stuff. > > > > > > > > > > > > > > > > - use mvn jetty:run in java/social-api to > > > > > > > > > > > > > > > > run the > > > > > > > > > > > > > > > > social server > > > > > > > > > > > > > > > > (ie > > > > > > > > > > > > > > > > the socialdata servlet) this has to be done > > > > > > > > > > > > > > > > after > > > > > > > > > > > > > > > > the compile. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We could do mvn:jetty-run in the top > > > > > > > > > > > > > > > > directory if > > > > > > > > > > > > > > > > we put in a > > > > > > > > > > > > > > > > web.xml > > > > > > > > > > > > > > > > file. This may be the best option for the > > > > > > > > > > > > > > > > samplecontainer and > > > > > > > > > > > > > > > > example > > > > > > > > > > > > > > > > friends. > > > > > > > > > > > > > > > > Oh, and please tell me if there is a better > > > > > > > > > > > > > > > > way > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > to > > > > > > > do this! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please review this patch, I would like it to > > > > > > > > > > > > > > > > go > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > in > > > > > > > soon: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/SHINDIG-199 > > > > > > > > > > > > > > > > > > > > > > > And note: this is a regression! So after I > > > > > > > > > > > > > > > > commit > > > > > > > > > > > > > > > > this people > > > > > > > > > > > > > > > > should > > > > > > > > > > > > > > > > probably not sync up their svn clients if > > > > > > > > > > > > > > > > they > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > are > > > > > > > dependent on > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > samplecontainer or the tight integration > > > > > > > > > > > > > > > > between > > > > > > > > > > > > > > > > socialdata and > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > gagdet renderer. We'll fix it all again soon > > > > > > > > > > > > > > > > somehow. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Cassie > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ~Kevin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > ~Kevin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > ~Kevin > > > > > > > -- ~Kevin
