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/ to see 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 >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >
