Okay, I'll check in my thing cause I have no idea how the heck to do that, and then Ian can make a patch to fix it better. At least my thing gets all the silly file moves out of the way.
Sounds perfect :) - Cassie On Wed, Apr 16, 2008 at 2:51 AM, David Primmer <[EMAIL PROTECTED]> 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 >> >
