[
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.
