On Wed, Apr 16, 2008 at 4:59 PM, Chris Chabot <[EMAIL PROTECTED]> wrote:
> Well I'm a happy man today and started on structuring the PHP code layout > to a more sane and understandable one :) > > In the process i noticed a two inconsistencies between the gadget and > social data layout, specifically that > - the http handlers are in a gadgets/http folder in the gadget side, but in > the social side in the top level directory > - on the social side the 'Basic*' files are in a samplecontainer/ > directory, in gadgets their in the top level directory Yeah, this is definitely a good idea. We can put it on the long list that includes the maven fixes, iframe fixes and the java/common folder :) > > > Because I'm in a move happy mood now i've applied the following logic to > the PHP structure: > > common -> all shared files > */ -> basic files for gadgets & socialdata > */http -> http handlers > */samplecontainer -> Basic* files > > So the resulting structure folder is: > > /common > /gadgets > /gadgets/http > /gadgets/samplecontainer > /socialdata/ > /socialdata/http > /socialdata/samplecontainer > /socialdata/opensocial > /socialdata/opensocial/model > > This way i have a layout that i think people will be able to understand and > is consistent. Maybe it might be an idea to do the same samplecontainer/* > and http/* constancy work on the Java side of things too? > > Ugh now just one problem remains ... making this into a digestible patch, > that might be tricky because i also have about 130k of socialdata code that > still needs to land in svn thats part this patch now :) > > -- Chris > > > On Apr 16, 2008, at 1:30 PM, 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 >>>>> >>>>> >>> >>> >
