Re: [jira] Updated: (SHINDIG-200) Patch to construct server from jars and war overlays

[Cassie <do...@google.com>]

On Wed, Apr 16, 2008 at 6:50 PM, Ian Boston <ie...@tfd.co.uk> 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 <ie...@tfd.co.uk> 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 <ie...@tfd.co.uk> 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.
>>
>>
>