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
