I am about to update the patch I have after the 199. I havent moved things into common,but have created a module got social-api that you may want to replace or rename.
Looking at the patch 2 things pop up.1. Naming an artifact common could be confusing since when its pacaged it appears as WEB-INF/lib/common-1-SNAPSHOT.jar after seeing that I renamed to shindig-common
2. In the gadget.http.HttpGuiceModule I think you are double binding some things that havent been removed from DefaultGuiceModule
I guess they want to be in the Default?I will update my patch.... I think I have got everything in the right place. Here is a recap
features go into the gadgets jar (with js compression)config goes into the WEB-ING/classes of the gadgets-resources overlay (no js compression) javascript goes into both gadgets and social-api resources overlay (with js compression) ... so you can assemble either service or both.
common (currently empty in my patch) social-api and gadgets are jars Will attach the patch in a moment. Ian On 16 Apr 2008, at 16:57, Cassie Doll (JIRA) wrote:
[ https://issues.apache.org/jira/browse/SHINDIG-200? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]Cassie Doll updated SHINDIG-200: -------------------------------- Attachment: create_java_common_without_file_moves.patchI have attached a patch that gets rid of the java/social-api dependency on java/gadgets by creating a java/common directory. The patch itself does not include the files moves. These files needed to be moved from gadgets to common:D gadgets/src/main/java/org/apache/shindig/util/TimeSource.java D gadgets/src/main/java/org/apache/shindig/util/Crypto.javaD gadgets/src/main/java/org/apache/shindig/util/ BlobCrypterException.java D gadgets/src/main/java/org/apache/shindig/util/ InputStreamConsumer.javaD gadgets/src/main/java/org/apache/shindig/util/BlobCrypter.javaD gadgets/src/main/java/org/apache/shindig/util/ BasicBlobCrypter.java D gadgets/src/main/java/org/apache/shindig/util/ ResourceLoader.java D gadgets/src/main/java/org/apache/shindig/util/ BlobExpiredException.java D gadgets/src/main/java/org/apache/shindig/gadgets/http/ GuiceServletContextListener.java D gadgets/src/main/java/org/apache/shindig/gadgets/http/ InjectedServlet.java D gadgets/src/main/java/org/apache/shindig/gadgets/ RemoteContentRequest.java D gadgets/src/main/java/org/apache/shindig/gadgets/ BasicGadgetTokenDecoder.java D gadgets/src/main/java/org/apache/shindig/gadgets/ RemoteContentFetcher.java D gadgets/src/main/java/org/apache/shindig/gadgets/ BasicGadgetToken.java D gadgets/src/main/java/org/apache/shindig/gadgets/ GadgetException.java D gadgets/src/main/java/org/apache/shindig/gadgets/ GadgetTokenDecoder.java D gadgets/src/main/java/org/apache/shindig/gadgets/ RemoteContent.java D gadgets/src/main/java/org/apache/shindig/gadgets/ BasicRemoteContentFetcher.java D gadgets/src/main/java/org/apache/shindig/gadgets/ GadgetToken.javaFor now I did not rename nor refactor anything... which we will want to do at some point. This patch purely cleans us our dependency tree and makes way for more refactoring.If there aren't any objections we should get this in so that an even better version of Ian's patch can be committed.Patch to construct server from jars and war overlays ---------------------------------------------------- Key: SHINDIG-200URL: https://issues.apache.org/jira/browse/ SHINDIG-200Project: Shindig Issue Type: Improvement Reporter: Ian BostonAttachments: create_java_common_without_file_moves.patch, serverbuild.patchFrom the list: +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 meansthat 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 certainabout 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.xmlthat 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 wouldenable both to run, and for others to construct a target.Perhaps thats too complex and there could be some simplification.... Iwould 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 IDchanges 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 htmland 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 customizethe 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 wantto do for our deployments at google, and I'm sure it's a model that other people would like as well. Ian-- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
