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