+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
