On Wed, Apr 16, 2008 at 6:50 PM, Ian Boston <[EMAIL PROTECTED]> wrote:
> 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 oh, very good point. i reverted all of those changes in my client. that was from an earlier refactoring that i went back on... > > > 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.patch >> >> I 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.java >> D >> gadgets/src/main/java/org/apache/shindig/util/BlobCrypterException.java >> D >> gadgets/src/main/java/org/apache/shindig/util/InputStreamConsumer.java >> D gadgets/src/main/java/org/apache/shindig/util/BlobCrypter.java >> D 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.java >> >> For 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-200 >>> URL: https://issues.apache.org/jira/browse/SHINDIG-200 >>> Project: Shindig >>> Issue Type: Improvement >>> Reporter: Ian Boston >>> Attachments: create_java_common_without_file_moves.patch, >>> serverbuild.patch >>> >>> >>> From 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 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 >>> >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> >
