You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Cassie <do...@apache.org> on 2008/04/15 18:08:08 UTC
Getting the socialdata servlet and friends into java/social-api
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
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Cassie <do...@apache.org>.
On Wed, Apr 16, 2008 at 4:59 PM, Chris Chabot <ch...@xs4all.nl> wrote:
> Well I'm a happy man today and started on structuring the PHP code layout
> to a more sane and understandable one :)
>
> In the process i noticed a two inconsistencies between the gadget and
> social data layout, specifically that
> - the http handlers are in a gadgets/http folder in the gadget side, but in
> the social side in the top level directory
> - on the social side the 'Basic*' files are in a samplecontainer/
> directory, in gadgets their in the top level directory
Yeah, this is definitely a good idea. We can put it on the long list that
includes the maven fixes, iframe fixes and the java/common folder :)
>
>
> Because I'm in a move happy mood now i've applied the following logic to
> the PHP structure:
>
> common -> all shared files
> */ -> basic files for gadgets & socialdata
> */http -> http handlers
> */samplecontainer -> Basic* files
>
> So the resulting structure folder is:
>
> /common
> /gadgets
> /gadgets/http
> /gadgets/samplecontainer
> /socialdata/
> /socialdata/http
> /socialdata/samplecontainer
> /socialdata/opensocial
> /socialdata/opensocial/model
>
> This way i have a layout that i think people will be able to understand and
> is consistent. Maybe it might be an idea to do the same samplecontainer/*
> and http/* constancy work on the Java side of things too?
>
> Ugh now just one problem remains ... making this into a digestible patch,
> that might be tricky because i also have about 130k of socialdata code that
> still needs to land in svn thats part this patch now :)
>
> -- Chris
>
>
> On Apr 16, 2008, at 1:30 PM, Cassie wrote:
>
> Alright Ian - my change is in, so let's make yours work.
>>
>> Should we pull out a java/common directory that both gadgets and the
>> social-api poms depend on? We could check in an empty directory for
>> now just as a place holder so that we can get the structure right.
>>
>> As for the resources:
>> - features = gadgets server
>> - config = gadgets server
>> - javascript = a joint server which has both gadgets and social-api
>> running?
>>
>> I think that is close to what we may want...
>>
>> - Cassie
>>
>>
>> On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>>> Done
>>> https://issues.apache.org/jira/browse/SHINDIG-200
>>>
>>> Its not complete since it needs the changes from 199, and also needs
>>> clarification on which resources are part of which server (the javascript
>>> files etc)
>>>
>>> It will run using jetty:run, but the only drawback is that now that the
>>> wars
>>> are overlaid, it takes a mvn compile (in a separate window) to get the
>>> files
>>> into a place where jetty will notice they have changed.
>>>
>>> Ian
>>>
>>>
>>>
>>> On 16 Apr 2008, at 01:51, David Primmer wrote:
>>>
>>>>
>>>> Sound good. Looking forward to the patch.
>>>>
>>>>
>>>> On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <et...@google.com> wrote:
>>>>
>>>>>
>>>>> +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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 15 Apr 2008, at 17:08, Cassie wrote:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> ~Kevin
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> ~Kevin
>>>>>
>>>>>
>>>
>>>
>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Chris Chabot <ch...@xs4all.nl>.
Well I'm a happy man today and started on structuring the PHP code
layout to a more sane and understandable one :)
In the process i noticed a two inconsistencies between the gadget and
social data layout, specifically that
- the http handlers are in a gadgets/http folder in the gadget side,
but in the social side in the top level directory
- on the social side the 'Basic*' files are in a samplecontainer/
directory, in gadgets their in the top level directory
Because I'm in a move happy mood now i've applied the following logic
to the PHP structure:
common -> all shared files
*/ -> basic files for gadgets & socialdata
*/http -> http handlers
*/samplecontainer -> Basic* files
So the resulting structure folder is:
/common
/gadgets
/gadgets/http
/gadgets/samplecontainer
/socialdata/
/socialdata/http
/socialdata/samplecontainer
/socialdata/opensocial
/socialdata/opensocial/model
This way i have a layout that i think people will be able to
understand and is consistent. Maybe it might be an idea to do the same
samplecontainer/* and http/* constancy work on the Java side of
things too?
Ugh now just one problem remains ... making this into a digestible
patch, that might be tricky because i also have about 130k of
socialdata code that still needs to land in svn thats part this patch
now :)
-- Chris
On Apr 16, 2008, at 1:30 PM, Cassie wrote:
> Alright Ian - my change is in, so let's make yours work.
>
> Should we pull out a java/common directory that both gadgets and the
> social-api poms depend on? We could check in an empty directory for
> now just as a place holder so that we can get the structure right.
>
> As for the resources:
> - features = gadgets server
> - config = gadgets server
> - javascript = a joint server which has both gadgets and social-api
> running?
>
> I think that is close to what we may want...
>
> - Cassie
>
>
> On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>> Done
>> https://issues.apache.org/jira/browse/SHINDIG-200
>>
>> Its not complete since it needs the changes from 199, and also needs
>> clarification on which resources are part of which server (the
>> javascript
>> files etc)
>>
>> It will run using jetty:run, but the only drawback is that now that
>> the wars
>> are overlaid, it takes a mvn compile (in a separate window) to get
>> the files
>> into a place where jetty will notice they have changed.
>>
>> Ian
>>
>>
>>
>> On 16 Apr 2008, at 01:51, David Primmer wrote:
>>>
>>> Sound good. Looking forward to the patch.
>>>
>>>
>>> On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <et...@google.com>
>>> wrote:
>>>>
>>>> +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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 15 Apr 2008, at 17:08, Cassie wrote:
>>>>>>>
>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ~Kevin
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ~Kevin
>>>>
>>
>>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Ian Boston <ie...@tfd.co.uk>.
Ignore my last message, 'need to open my eyes wider'. Just the
DefaultGuiceModule is an issue.
Ian
On 16 Apr 2008, at 12:30, Cassie wrote:
> Alright Ian - my change is in, so let's make yours work.
>
> Should we pull out a java/common directory that both gadgets and the
> social-api poms depend on? We could check in an empty directory for
> now just as a place holder so that we can get the structure right.
>
> As for the resources:
> - features = gadgets server
> - config = gadgets server
> - javascript = a joint server which has both gadgets and social-api
> running?
>
> I think that is close to what we may want...
>
> - Cassie
>
>
> On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>> Done
>> https://issues.apache.org/jira/browse/SHINDIG-200
>>
>> Its not complete since it needs the changes from 199, and also needs
>> clarification on which resources are part of which server (the
>> javascript
>> files etc)
>>
>> It will run using jetty:run, but the only drawback is that now
>> that the wars
>> are overlaid, it takes a mvn compile (in a separate window) to get
>> the files
>> into a place where jetty will notice they have changed.
>>
>> Ian
>>
>>
>>
>> On 16 Apr 2008, at 01:51, David Primmer wrote:
>>>
>>> Sound good. Looking forward to the patch.
>>>
>>>
>>> On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <et...@google.com>
>>> wrote:
>>>>
>>>> +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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 15 Apr 2008, at 17:08, Cassie wrote:
>>>>>>>
>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ~Kevin
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ~Kevin
>>>>
>>
>>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Cassie <do...@google.com>.
Thanks for all of your help Ian, this wouldn't have gotten done without you.
Hopefully we are all good now.
- Cassie
On Sat, Apr 19, 2008 at 10:28 AM, Ian Boston <ie...@tfd.co.uk> wrote:
>
> Ahhh,
> Sorry, I was being dumb......
>
> ../../javascript is only a sample and is *not* vital to running the
> services.
>
> Ignore me, Cassies patch is smaller, cleaner and .... right.
>
> Sorry
> Ian
>
>
>
> On 18 Apr 2008, at 22:11, Kevin Brown wrote:
>>
>> Someone pulling in shindig from maven would be pulling in the appropriate
>> jars (gadget rendering, social api, or both). The sample files really
>> only
>> belong in the sample web app, because that's all they are -- samples. The
>> resources required for actually running (feature.xml files, properties
>> files, etc.) are pretty closely tied to a specific jar, and as such should
>> be bundled as ordinary resources within those artifacts.
>
>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Ian Boston <ie...@tfd.co.uk>.
Ahhh,
Sorry, I was being dumb......
../../javascript is only a sample and is *not* vital to running the
services.
Ignore me, Cassies patch is smaller, cleaner and .... right.
Sorry
Ian
On 18 Apr 2008, at 22:11, Kevin Brown wrote:
> Someone pulling in shindig from maven would be pulling in the
> appropriate
> jars (gadget rendering, social api, or both). The sample files
> really only
> belong in the sample web app, because that's all they are --
> samples. The
> resources required for actually running (feature.xml files, properties
> files, etc.) are pretty closely tied to a specific jar, and as such
> should
> be bundled as ordinary resources within those artifacts.
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Kevin Brown <et...@google.com>.
On Fri, Apr 18, 2008 at 4:56 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> Cassie's approach is perfectly valid.
>
> Some clarification of my thinking which is focused on the
> 'users/implementors' of the software outputs of Shindig.
>
> The only reason for the resources was that, when you do a release of
> Shindig. You will put things into repo2.apache.org as artifacts.
>
> Putting the server.war in there will make it harder for an implementor to
> build a custom deployment using their own pom with overlays, since the
> filtering will be complex.
>
> Putting the resource overlays in should make it easier to build one, or
> both of the services.
>
> As I said Cassie's approach is valid, probably better for the project
> developers, but might be harder for someone using shindig as a dependency
> from the maven repo. (always, assuming they work that way)
Someone pulling in shindig from maven would be pulling in the appropriate
jars (gadget rendering, social api, or both). The sample files really only
belong in the sample web app, because that's all they are -- samples. The
resources required for actually running (feature.xml files, properties
files, etc.) are pretty closely tied to a specific jar, and as such should
be bundled as ordinary resources within those artifacts.
>
> Ian
>
>
>
>
> On 18 Apr 2008, at 09:57, Cassie wrote:
>
> > So I got something working on my box which is similar to yours Ian but
> > eliminates the *-resources projects. In order to do this I just directly
> > had
> > the java/server thing directly declare the conf and javascript files and
> > what not to be resources.
> >
> > I personally didn't think this was so bad because its like how the
> > web.xml
> > thing works, everything is just sorta duplicated. I also like this
> > because I
> > could still run java/gadgets by itself and have it pull down the example
> > files. (as opposed to having to build the resources directory as well
> > and
> > run them together - although perhaps i just screwed that up)
> >
> > So... what do the people listening to this think:
> > 1. Ian's patch which pulls out two overlay wars gadgets-resources and
> > social-resources to specify which resources each server needs
> > 2. A slightly modified version which takes the stuff in Ian's
> > *-resources
> > poms and drops it into the server/pom. This basically hardcodes the
> > resources the java/server pom needs while removing the two overlay wars.
> >
> > Thanks.
> >
> > - Cassie
> >
> > ps - Kevin - I didn't understand what you said at all
> >
> > On Fri, Apr 18, 2008 at 1:34 AM, Kevin Brown <et...@google.com> wrote:
> >
> > I don't think the resource files are necessary to achieve this. There's
> > > no
> > > reason to have the web resources published statically anywhere but in
> > > the
> > > webapp (the war), so therefore that's the only thing that needs to
> > > worry
> > > about it. The other resources are common to all language
> > > implementations,
> > > and should be pulled in by the appropriate artifacts using relative
> > > paths
> > > as
> > > they are currently.
> > >
> > > On Thu, Apr 17, 2008 at 2:00 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> > >
> > > Cassie,
> > > >
> > > > Sorry for the delay in responding, been in local project
> > > > planing/panic
> > > > mode today :)
> > > >
> > > > social-api and gadgets pack into jars, that end up as dependencies
> > > > in
> > > > WEB-INF/lib when the final war is built. The things that need to be
> > > > on
> > > >
> > > the
> > >
> > > > classpath are in those files.
> > > >
> > > > social-api-resources and gadgets-resources contain the files we want
> > > > exposed in the webapp, so they need to be wars (or perhaps zips).
> > > > When
> > > >
> > > they
> > >
> > > > are pulled in in the build of the final war they are overlayed.
> > > >
> > > > Unfortunately this generates lots of artifacts and poms, 6 (3 jars,
> > > > 2
> > > > overlay wars, 1 target war).
> > > >
> > > > We cant put the contents of the overlay wars into the jars, because
> > > > they
> > > > a) are not part of the classpath b) probably dont make sense being
> > > > overlayed.
> > > >
> > > > We could put both resource builds into the target war build
> > > > (server.war),
> > > > but then they would not end up in the maven repo, and so it would
> > > > not be
> > > > possible for 3rd parties to generate a war from the maven repo.
> > > >
> > > > We could merge the overlay wars into 1 war, but then we would end up
> > > > with
> > > > all the social files in a gadget server (and visa versa)
> > > >
> > > > So..... I think the 3 jars, 2 overlays and one target offers
> > > > flexibility,
> > > > while keeping the build automated..... but I am always open to
> > > >
> > > suggestions.
> > >
> > > >
> > > >
> > > > The conf directory in social-api and gadgets contains the Guice
> > > >
> > > properties
> > >
> > > > file for each respective Module (eg gadgets.properties and
> > > > social.properties), that needs to be in the classpath, and hence is
> > > >
> > > packed
> > >
> > > > with the Jar. I think I am right in saying that if someone wanted to
> > > >
> > > provide
> > >
> > > > their own set of properties, a file ending up in WEB-INF/classes
> > > > would
> > > >
> > > take
> > >
> > > > precedence when the classloader performs the resolution.
> > > >
> > > > You may be using a name other than social.properites.
> > > >
> > > > I hope that makes sense, if it doesn't, its almost certainly my poor
> > > > explanation, so please ask questions.
> > > >
> > > > Ian
> > > >
> > > >
> > > >
> > > >
> > > > On 17 Apr 2008, at 16:07, Cassie wrote:
> > > >
> > > > Alright, Ian I grabbed most of the easy stuff in your patch and I
> > > > > think
> > > > > I'm
> > > > > getting a better idea of what the rest of it does. Just one quick
> > > > > question
> > > > > though - do we really need to separate out the *-resources
> > > > > projects
> > > > >
> > > > from
> > >
> > > > the
> > > > > java/gadgets and java/social-api poms? If we add in everything in
> > > > > the
> > > > > patch
> > > > > we will end up with 6 sub directories, and 8 total pom files :(
> > > > > If we
> > > > > can
> > > > > package the resources up with the servers themselves then at least
> > > > > we
> > > > > are
> > > > > back down to 4 modules.
> > > > >
> > > > > Aside from that it looks good although I don't understand what the
> > > > > new
> > > > > conf
> > > > > directory is in the social and gadgets pom files:
> > > > > + <resources>
> > > > > + <resource>
> > > > > + <directory>conf</directory>
> > > > > + </resource>
> > > > > + </resources>
> > > > >
> > > > > Thanks for bearing with my naiveté!
> > > > >
> > > > > - Cassie
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Apr 16, 2008 at 7:00 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> > > > >
> > > > > Ok,
> > > > >
> > > > > > I've updated the patch on 200,
> > > > > >
> > > > > >
> > > > > > do you want me to pull your patch in locally, merge with my one
> > > > > > and
> > > > > > then
> > > > > > update my patch on 200.
> > > > > >
> > > > > > or
> > > > > >
> > > > > > do you want to take the patch I have put on 200
> > > > > > (serverbuild2.patch)
> > > > > > and
> > > > > > merge with yours.
> > > > > >
> > > > > > If you take SocialApiGuiceModule, then I have no mv or cp
> > > > > > operations,
> > > > > > so I
> > > > > > might be easier that way round as you have commit.
> > > > > >
> > > > > > I'm Ok either way.... except its getting close to kids bedtime
> > > > > > GMT,
> > > > > >
> > > > > so
> > >
> > > > I
> > > > > > will soon go offline for a few hours.
> > > > > >
> > > > > > Ian
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 16 Apr 2008, at 17:21, Cassie wrote:
> > > > > >
> > > > > > Yeah, I saw these too and fixed them in the patch I attached to
> > > > > >
> > > > > > > SHINDIG-200.
> > > > > > >
> > > > > > > I ended up making a new SocialApiGuiceModule for the social
> > > > > > >
> > > > > > specific
> > >
> > > > guice
> > > > > > > stuff and moving a bunch of files into common.
> > > > > > >
> > > > > > > - Cassie
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Apr 16, 2008 at 5:49 PM, Ian Boston <ie...@tfd.co.uk>
> > > > > > > wrote:
> > > > > > >
> > > > > > > I am finding some build problems, Ok to fix in my patch ?
> > > > > > >
> > > > > > >
> > > > > > > > 1. The shared dependency of GadgetDataHandler in both
> > > > > > > > gasdget and
> > > > > > > > social
> > > > > > > > 2. The DefaultGuiceModule that needs to be split.
> > > > > > > >
> > > > > > > > If ok I am going to move to common. I will keep a list of
> > > > > > > > svn
> > > > > > > > commands.
> > > > > > > >
> > > > > > > >
> > > > > > > > Ian
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 16 Apr 2008, at 12:30, Cassie wrote:
> > > > > > > >
> > > > > > > > Alright Ian - my change is in, so let's make yours work.
> > > > > > > >
> > > > > > > >
> > > > > > > > > Should we pull out a java/common directory that both
> > > > > > > > > gadgets
> > > > > > > > >
> > > > > > > > and
> > >
> > > > the
> > > > > > > > > social-api poms depend on? We could check in an empty
> > > > > > > > > directory
> > > > > > > > > for
> > > > > > > > > now just as a place holder so that we can get the
> > > > > > > > > structure
> > > > > > > > > right.
> > > > > > > > >
> > > > > > > > > As for the resources:
> > > > > > > > > - features = gadgets server
> > > > > > > > > - config = gadgets server
> > > > > > > > > - javascript = a joint server which has both gadgets and
> > > > > > > > > social-api
> > > > > > > > > running?
> > > > > > > > >
> > > > > > > > > I think that is close to what we may want...
> > > > > > > > >
> > > > > > > > > - Cassie
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <
> > > > > > > > > ieb@tfd.co.uk>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Done
> > > > > > > > >
> > > > > > > > > https://issues.apache.org/jira/browse/SHINDIG-200
> > > > > > > > > >
> > > > > > > > > > Its not complete since it needs the changes from 199,
> > > > > > > > > > and
> > > > > > > > > >
> > > > > > > > > also
> > >
> > > > needs
> > > > > > > > > > clarification on which resources are part of which
> > > > > > > > > > server
> > > > > > > > > >
> > > > > > > > > (the
> > >
> > > > javascript
> > > > > > > > > > files etc)
> > > > > > > > > >
> > > > > > > > > > It will run using jetty:run, but the only drawback is
> > > > > > > > > > that
> > > > > > > > > >
> > > > > > > > > now
> > >
> > > > that the
> > > > > > > > > > wars
> > > > > > > > > > are overlaid, it takes a mvn compile (in a separate
> > > > > > > > > > window)
> > > > > > > > > >
> > > > > > > > > to
> > >
> > > > get the
> > > > > > > > > > files
> > > > > > > > > > into a place where jetty will notice they have changed.
> > > > > > > > > >
> > > > > > > > > > Ian
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 16 Apr 2008, at 01:51, David Primmer wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Sound good. Looking forward to the patch.
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <
> > > > > > > > > > > etnu@google.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > +1 -- I like this a lot, even if it is slightly more
> > > > > > > > > > >
> > > > > > > > > > > > complex.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Apr 15, 2008 at 5:13 PM, Ian Boston <
> > > > > > > > > > > > ieb@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/tosee 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 <
> > > > > > > > > > > > > ieb@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
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 15 Apr 2008, at 17:08, Cassie wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > ~Kevin
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > >
> > > > > > > > > > > > ~Kevin
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > >
> > > --
> > > ~Kevin
> > >
> > >
>
--
~Kevin
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Kevin Brown <et...@google.com>.
I said to do exactly what you did :)
On Fri, Apr 18, 2008 at 1:57 AM, Cassie <do...@apache.org> wrote:
> So I got something working on my box which is similar to yours Ian but
> eliminates the *-resources projects. In order to do this I just directly
> had
> the java/server thing directly declare the conf and javascript files and
> what not to be resources.
>
> I personally didn't think this was so bad because its like how the web.xml
> thing works, everything is just sorta duplicated. I also like this because
> I
> could still run java/gadgets by itself and have it pull down the example
> files. (as opposed to having to build the resources directory as well and
> run them together - although perhaps i just screwed that up)
>
> So... what do the people listening to this think:
> 1. Ian's patch which pulls out two overlay wars gadgets-resources and
> social-resources to specify which resources each server needs
> 2. A slightly modified version which takes the stuff in Ian's *-resources
> poms and drops it into the server/pom. This basically hardcodes the
> resources the java/server pom needs while removing the two overlay wars.
>
> Thanks.
>
> - Cassie
>
> ps - Kevin - I didn't understand what you said at all
>
> On Fri, Apr 18, 2008 at 1:34 AM, Kevin Brown <et...@google.com> wrote:
>
> > I don't think the resource files are necessary to achieve this. There's
> no
> > reason to have the web resources published statically anywhere but in
> the
> > webapp (the war), so therefore that's the only thing that needs to worry
> > about it. The other resources are common to all language
> implementations,
> > and should be pulled in by the appropriate artifacts using relative
> paths
> > as
> > they are currently.
> >
> > On Thu, Apr 17, 2008 at 2:00 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> >
> > > Cassie,
> > >
> > > Sorry for the delay in responding, been in local project planing/panic
> > > mode today :)
> > >
> > > social-api and gadgets pack into jars, that end up as dependencies in
> > > WEB-INF/lib when the final war is built. The things that need to be on
> > the
> > > classpath are in those files.
> > >
> > > social-api-resources and gadgets-resources contain the files we want
> > > exposed in the webapp, so they need to be wars (or perhaps zips).
> When
> > they
> > > are pulled in in the build of the final war they are overlayed.
> > >
> > > Unfortunately this generates lots of artifacts and poms, 6 (3 jars, 2
> > > overlay wars, 1 target war).
> > >
> > > We cant put the contents of the overlay wars into the jars, because
> they
> > > a) are not part of the classpath b) probably dont make sense being
> > > overlayed.
> > >
> > > We could put both resource builds into the target war build
> (server.war),
> > > but then they would not end up in the maven repo, and so it would not
> be
> > > possible for 3rd parties to generate a war from the maven repo.
> > >
> > > We could merge the overlay wars into 1 war, but then we would end up
> with
> > > all the social files in a gadget server (and visa versa)
> > >
> > > So..... I think the 3 jars, 2 overlays and one target offers
> flexibility,
> > > while keeping the build automated..... but I am always open to
> > suggestions.
> > >
> > >
> > > The conf directory in social-api and gadgets contains the Guice
> > properties
> > > file for each respective Module (eg gadgets.properties and
> > > social.properties), that needs to be in the classpath, and hence is
> > packed
> > > with the Jar. I think I am right in saying that if someone wanted to
> > provide
> > > their own set of properties, a file ending up in WEB-INF/classes would
> > take
> > > precedence when the classloader performs the resolution.
> > >
> > > You may be using a name other than social.properites.
> > >
> > > I hope that makes sense, if it doesn't, its almost certainly my poor
> > > explanation, so please ask questions.
> > >
> > > Ian
> > >
> > >
> > >
> > >
> > > On 17 Apr 2008, at 16:07, Cassie wrote:
> > >
> > > > Alright, Ian I grabbed most of the easy stuff in your patch and I
> think
> > > > I'm
> > > > getting a better idea of what the rest of it does. Just one quick
> > > > question
> > > > though - do we really need to separate out the *-resources projects
> > from
> > > > the
> > > > java/gadgets and java/social-api poms? If we add in everything in
> the
> > > > patch
> > > > we will end up with 6 sub directories, and 8 total pom files :( If
> we
> > > > can
> > > > package the resources up with the servers themselves then at least
> we
> > > > are
> > > > back down to 4 modules.
> > > >
> > > > Aside from that it looks good although I don't understand what the
> new
> > > > conf
> > > > directory is in the social and gadgets pom files:
> > > > + <resources>
> > > > + <resource>
> > > > + <directory>conf</directory>
> > > > + </resource>
> > > > + </resources>
> > > >
> > > > Thanks for bearing with my naiveté!
> > > >
> > > > - Cassie
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Apr 16, 2008 at 7:00 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> > > >
> > > > Ok,
> > > > > I've updated the patch on 200,
> > > > >
> > > > >
> > > > > do you want me to pull your patch in locally, merge with my one
> and
> > > > > then
> > > > > update my patch on 200.
> > > > >
> > > > > or
> > > > >
> > > > > do you want to take the patch I have put on 200
> (serverbuild2.patch)
> > > > > and
> > > > > merge with yours.
> > > > >
> > > > > If you take SocialApiGuiceModule, then I have no mv or cp
> operations,
> > > > > so I
> > > > > might be easier that way round as you have commit.
> > > > >
> > > > > I'm Ok either way.... except its getting close to kids bedtime
> GMT,
> > so
> > > > > I
> > > > > will soon go offline for a few hours.
> > > > >
> > > > > Ian
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 16 Apr 2008, at 17:21, Cassie wrote:
> > > > >
> > > > > Yeah, I saw these too and fixed them in the patch I attached to
> > > > > > SHINDIG-200.
> > > > > >
> > > > > > I ended up making a new SocialApiGuiceModule for the social
> > specific
> > > > > > guice
> > > > > > stuff and moving a bunch of files into common.
> > > > > >
> > > > > > - Cassie
> > > > > >
> > > > > >
> > > > > > On Wed, Apr 16, 2008 at 5:49 PM, Ian Boston <ie...@tfd.co.uk>
> wrote:
> > > > > >
> > > > > > I am finding some build problems, Ok to fix in my patch ?
> > > > > >
> > > > > > >
> > > > > > > 1. The shared dependency of GadgetDataHandler in both gasdget
> and
> > > > > > > social
> > > > > > > 2. The DefaultGuiceModule that needs to be split.
> > > > > > >
> > > > > > > If ok I am going to move to common. I will keep a list of svn
> > > > > > > commands.
> > > > > > >
> > > > > > >
> > > > > > > Ian
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 16 Apr 2008, at 12:30, Cassie wrote:
> > > > > > >
> > > > > > > Alright Ian - my change is in, so let's make yours work.
> > > > > > >
> > > > > > > >
> > > > > > > > Should we pull out a java/common directory that both gadgets
> > and
> > > > > > > > the
> > > > > > > > social-api poms depend on? We could check in an empty
> directory
> > > > > > > > for
> > > > > > > > now just as a place holder so that we can get the structure
> > > > > > > > right.
> > > > > > > >
> > > > > > > > As for the resources:
> > > > > > > > - features = gadgets server
> > > > > > > > - config = gadgets server
> > > > > > > > - javascript = a joint server which has both gadgets and
> > > > > > > > social-api
> > > > > > > > running?
> > > > > > > >
> > > > > > > > I think that is close to what we may want...
> > > > > > > >
> > > > > > > > - Cassie
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > Done
> > > > > > > >
> > > > > > > > > https://issues.apache.org/jira/browse/SHINDIG-200
> > > > > > > > >
> > > > > > > > > Its not complete since it needs the changes from 199, and
> > also
> > > > > > > > > needs
> > > > > > > > > clarification on which resources are part of which server
> > (the
> > > > > > > > > javascript
> > > > > > > > > files etc)
> > > > > > > > >
> > > > > > > > > It will run using jetty:run, but the only drawback is that
> > now
> > > > > > > > > that the
> > > > > > > > > wars
> > > > > > > > > are overlaid, it takes a mvn compile (in a separate
> window)
> > to
> > > > > > > > > get the
> > > > > > > > > files
> > > > > > > > > into a place where jetty will notice they have changed.
> > > > > > > > >
> > > > > > > > > Ian
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 16 Apr 2008, at 01:51, David Primmer wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Sound good. Looking forward to the patch.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <
> > > > > > > > > > etnu@google.com> wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > +1 -- I like this a lot, even if it is slightly more
> > > > > > > > > > > complex.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Apr 15, 2008 at 5:13 PM, Ian Boston <
> > > > > > > > > > > ieb@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 <
> > > > > > > > > > > > ieb@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
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 15 Apr 2008, at 17:08, Cassie wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 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
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > >
> > > > > > > > > > > > > ~Kevin
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > ~Kevin
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> >
> >
> > --
> > ~Kevin
> >
>
--
~Kevin
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Ian Boston <ie...@tfd.co.uk>.
Cassie's approach is perfectly valid.
Some clarification of my thinking which is focused on the 'users/
implementors' of the software outputs of Shindig.
The only reason for the resources was that, when you do a release of
Shindig. You will put things into repo2.apache.org as artifacts.
Putting the server.war in there will make it harder for an
implementor to build a custom deployment using their own pom with
overlays, since the filtering will be complex.
Putting the resource overlays in should make it easier to build one,
or both of the services.
As I said Cassie's approach is valid, probably better for the project
developers, but might be harder for someone using shindig as a
dependency from the maven repo. (always, assuming they work that way)
Ian
On 18 Apr 2008, at 09:57, Cassie wrote:
> So I got something working on my box which is similar to yours Ian but
> eliminates the *-resources projects. In order to do this I just
> directly had
> the java/server thing directly declare the conf and javascript
> files and
> what not to be resources.
>
> I personally didn't think this was so bad because its like how the
> web.xml
> thing works, everything is just sorta duplicated. I also like this
> because I
> could still run java/gadgets by itself and have it pull down the
> example
> files. (as opposed to having to build the resources directory as
> well and
> run them together - although perhaps i just screwed that up)
>
> So... what do the people listening to this think:
> 1. Ian's patch which pulls out two overlay wars gadgets-resources and
> social-resources to specify which resources each server needs
> 2. A slightly modified version which takes the stuff in Ian's *-
> resources
> poms and drops it into the server/pom. This basically hardcodes the
> resources the java/server pom needs while removing the two overlay
> wars.
>
> Thanks.
>
> - Cassie
>
> ps - Kevin - I didn't understand what you said at all
>
> On Fri, Apr 18, 2008 at 1:34 AM, Kevin Brown <et...@google.com> wrote:
>
>> I don't think the resource files are necessary to achieve this.
>> There's no
>> reason to have the web resources published statically anywhere but
>> in the
>> webapp (the war), so therefore that's the only thing that needs to
>> worry
>> about it. The other resources are common to all language
>> implementations,
>> and should be pulled in by the appropriate artifacts using
>> relative paths
>> as
>> they are currently.
>>
>> On Thu, Apr 17, 2008 at 2:00 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>>> Cassie,
>>>
>>> Sorry for the delay in responding, been in local project planing/
>>> panic
>>> mode today :)
>>>
>>> social-api and gadgets pack into jars, that end up as
>>> dependencies in
>>> WEB-INF/lib when the final war is built. The things that need to
>>> be on
>> the
>>> classpath are in those files.
>>>
>>> social-api-resources and gadgets-resources contain the files we want
>>> exposed in the webapp, so they need to be wars (or perhaps
>>> zips). When
>> they
>>> are pulled in in the build of the final war they are overlayed.
>>>
>>> Unfortunately this generates lots of artifacts and poms, 6 (3
>>> jars, 2
>>> overlay wars, 1 target war).
>>>
>>> We cant put the contents of the overlay wars into the jars,
>>> because they
>>> a) are not part of the classpath b) probably dont make sense being
>>> overlayed.
>>>
>>> We could put both resource builds into the target war build
>>> (server.war),
>>> but then they would not end up in the maven repo, and so it would
>>> not be
>>> possible for 3rd parties to generate a war from the maven repo.
>>>
>>> We could merge the overlay wars into 1 war, but then we would end
>>> up with
>>> all the social files in a gadget server (and visa versa)
>>>
>>> So..... I think the 3 jars, 2 overlays and one target offers
>>> flexibility,
>>> while keeping the build automated..... but I am always open to
>> suggestions.
>>>
>>>
>>> The conf directory in social-api and gadgets contains the Guice
>> properties
>>> file for each respective Module (eg gadgets.properties and
>>> social.properties), that needs to be in the classpath, and hence is
>> packed
>>> with the Jar. I think I am right in saying that if someone wanted to
>> provide
>>> their own set of properties, a file ending up in WEB-INF/classes
>>> would
>> take
>>> precedence when the classloader performs the resolution.
>>>
>>> You may be using a name other than social.properites.
>>>
>>> I hope that makes sense, if it doesn't, its almost certainly my poor
>>> explanation, so please ask questions.
>>>
>>> Ian
>>>
>>>
>>>
>>>
>>> On 17 Apr 2008, at 16:07, Cassie wrote:
>>>
>>>> Alright, Ian I grabbed most of the easy stuff in your patch and
>>>> I think
>>>> I'm
>>>> getting a better idea of what the rest of it does. Just one quick
>>>> question
>>>> though - do we really need to separate out the *-resources projects
>> from
>>>> the
>>>> java/gadgets and java/social-api poms? If we add in everything
>>>> in the
>>>> patch
>>>> we will end up with 6 sub directories, and 8 total pom files :
>>>> ( If we
>>>> can
>>>> package the resources up with the servers themselves then at
>>>> least we
>>>> are
>>>> back down to 4 modules.
>>>>
>>>> Aside from that it looks good although I don't understand what
>>>> the new
>>>> conf
>>>> directory is in the social and gadgets pom files:
>>>> + <resources>
>>>> + <resource>
>>>> + <directory>conf</directory>
>>>> + </resource>
>>>> + </resources>
>>>>
>>>> Thanks for bearing with my naiveté!
>>>>
>>>> - Cassie
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Apr 16, 2008 at 7:00 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>
>>>> Ok,
>>>>> I've updated the patch on 200,
>>>>>
>>>>>
>>>>> do you want me to pull your patch in locally, merge with my one
>>>>> and
>>>>> then
>>>>> update my patch on 200.
>>>>>
>>>>> or
>>>>>
>>>>> do you want to take the patch I have put on 200
>>>>> (serverbuild2.patch)
>>>>> and
>>>>> merge with yours.
>>>>>
>>>>> If you take SocialApiGuiceModule, then I have no mv or cp
>>>>> operations,
>>>>> so I
>>>>> might be easier that way round as you have commit.
>>>>>
>>>>> I'm Ok either way.... except its getting close to kids bedtime
>>>>> GMT,
>> so
>>>>> I
>>>>> will soon go offline for a few hours.
>>>>>
>>>>> Ian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 16 Apr 2008, at 17:21, Cassie wrote:
>>>>>
>>>>> Yeah, I saw these too and fixed them in the patch I attached to
>>>>>> SHINDIG-200.
>>>>>>
>>>>>> I ended up making a new SocialApiGuiceModule for the social
>> specific
>>>>>> guice
>>>>>> stuff and moving a bunch of files into common.
>>>>>>
>>>>>> - Cassie
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 16, 2008 at 5:49 PM, Ian Boston <ie...@tfd.co.uk>
>>>>>> wrote:
>>>>>>
>>>>>> I am finding some build problems, Ok to fix in my patch ?
>>>>>>
>>>>>>>
>>>>>>> 1. The shared dependency of GadgetDataHandler in both gasdget
>>>>>>> and
>>>>>>> social
>>>>>>> 2. The DefaultGuiceModule that needs to be split.
>>>>>>>
>>>>>>> If ok I am going to move to common. I will keep a list of svn
>>>>>>> commands.
>>>>>>>
>>>>>>>
>>>>>>> Ian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 16 Apr 2008, at 12:30, Cassie wrote:
>>>>>>>
>>>>>>> Alright Ian - my change is in, so let's make yours work.
>>>>>>>
>>>>>>>>
>>>>>>>> Should we pull out a java/common directory that both gadgets
>> and
>>>>>>>> the
>>>>>>>> social-api poms depend on? We could check in an empty directory
>>>>>>>> for
>>>>>>>> now just as a place holder so that we can get the structure
>>>>>>>> right.
>>>>>>>>
>>>>>>>> As for the resources:
>>>>>>>> - features = gadgets server
>>>>>>>> - config = gadgets server
>>>>>>>> - javascript = a joint server which has both gadgets and
>>>>>>>> social-api
>>>>>>>> running?
>>>>>>>>
>>>>>>>> I think that is close to what we may want...
>>>>>>>>
>>>>>>>> - Cassie
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Done
>>>>>>>>
>>>>>>>>> https://issues.apache.org/jira/browse/SHINDIG-200
>>>>>>>>>
>>>>>>>>> Its not complete since it needs the changes from 199, and
>> also
>>>>>>>>> needs
>>>>>>>>> clarification on which resources are part of which server
>> (the
>>>>>>>>> javascript
>>>>>>>>> files etc)
>>>>>>>>>
>>>>>>>>> It will run using jetty:run, but the only drawback is that
>> now
>>>>>>>>> that the
>>>>>>>>> wars
>>>>>>>>> are overlaid, it takes a mvn compile (in a separate window)
>> to
>>>>>>>>> get the
>>>>>>>>> files
>>>>>>>>> into a place where jetty will notice they have changed.
>>>>>>>>>
>>>>>>>>> Ian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 16 Apr 2008, at 01:51, David Primmer wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sound good. Looking forward to the patch.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <
>>>>>>>>>> etnu@google.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +1 -- I like this a lot, even if it is slightly more
>>>>>>>>>>> complex.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Apr 15, 2008 at 5:13 PM, Ian Boston <
>>>>>>>>>>> ieb@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 <
>>>>>>>>>>>> ieb@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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 15 Apr 2008, at 17:08, Cassie wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>
>>>>>>>>>>>>> ~Kevin
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>> ~Kevin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>>
>> --
>> ~Kevin
>>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Cassie <do...@apache.org>.
So I got something working on my box which is similar to yours Ian but
eliminates the *-resources projects. In order to do this I just directly had
the java/server thing directly declare the conf and javascript files and
what not to be resources.
I personally didn't think this was so bad because its like how the web.xml
thing works, everything is just sorta duplicated. I also like this because I
could still run java/gadgets by itself and have it pull down the example
files. (as opposed to having to build the resources directory as well and
run them together - although perhaps i just screwed that up)
So... what do the people listening to this think:
1. Ian's patch which pulls out two overlay wars gadgets-resources and
social-resources to specify which resources each server needs
2. A slightly modified version which takes the stuff in Ian's *-resources
poms and drops it into the server/pom. This basically hardcodes the
resources the java/server pom needs while removing the two overlay wars.
Thanks.
- Cassie
ps - Kevin - I didn't understand what you said at all
On Fri, Apr 18, 2008 at 1:34 AM, Kevin Brown <et...@google.com> wrote:
> I don't think the resource files are necessary to achieve this. There's no
> reason to have the web resources published statically anywhere but in the
> webapp (the war), so therefore that's the only thing that needs to worry
> about it. The other resources are common to all language implementations,
> and should be pulled in by the appropriate artifacts using relative paths
> as
> they are currently.
>
> On Thu, Apr 17, 2008 at 2:00 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>
> > Cassie,
> >
> > Sorry for the delay in responding, been in local project planing/panic
> > mode today :)
> >
> > social-api and gadgets pack into jars, that end up as dependencies in
> > WEB-INF/lib when the final war is built. The things that need to be on
> the
> > classpath are in those files.
> >
> > social-api-resources and gadgets-resources contain the files we want
> > exposed in the webapp, so they need to be wars (or perhaps zips). When
> they
> > are pulled in in the build of the final war they are overlayed.
> >
> > Unfortunately this generates lots of artifacts and poms, 6 (3 jars, 2
> > overlay wars, 1 target war).
> >
> > We cant put the contents of the overlay wars into the jars, because they
> > a) are not part of the classpath b) probably dont make sense being
> > overlayed.
> >
> > We could put both resource builds into the target war build (server.war),
> > but then they would not end up in the maven repo, and so it would not be
> > possible for 3rd parties to generate a war from the maven repo.
> >
> > We could merge the overlay wars into 1 war, but then we would end up with
> > all the social files in a gadget server (and visa versa)
> >
> > So..... I think the 3 jars, 2 overlays and one target offers flexibility,
> > while keeping the build automated..... but I am always open to
> suggestions.
> >
> >
> > The conf directory in social-api and gadgets contains the Guice
> properties
> > file for each respective Module (eg gadgets.properties and
> > social.properties), that needs to be in the classpath, and hence is
> packed
> > with the Jar. I think I am right in saying that if someone wanted to
> provide
> > their own set of properties, a file ending up in WEB-INF/classes would
> take
> > precedence when the classloader performs the resolution.
> >
> > You may be using a name other than social.properites.
> >
> > I hope that makes sense, if it doesn't, its almost certainly my poor
> > explanation, so please ask questions.
> >
> > Ian
> >
> >
> >
> >
> > On 17 Apr 2008, at 16:07, Cassie wrote:
> >
> > > Alright, Ian I grabbed most of the easy stuff in your patch and I think
> > > I'm
> > > getting a better idea of what the rest of it does. Just one quick
> > > question
> > > though - do we really need to separate out the *-resources projects
> from
> > > the
> > > java/gadgets and java/social-api poms? If we add in everything in the
> > > patch
> > > we will end up with 6 sub directories, and 8 total pom files :( If we
> > > can
> > > package the resources up with the servers themselves then at least we
> > > are
> > > back down to 4 modules.
> > >
> > > Aside from that it looks good although I don't understand what the new
> > > conf
> > > directory is in the social and gadgets pom files:
> > > + <resources>
> > > + <resource>
> > > + <directory>conf</directory>
> > > + </resource>
> > > + </resources>
> > >
> > > Thanks for bearing with my naiveté!
> > >
> > > - Cassie
> > >
> > >
> > >
> > >
> > > On Wed, Apr 16, 2008 at 7:00 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> > >
> > > Ok,
> > > > I've updated the patch on 200,
> > > >
> > > >
> > > > do you want me to pull your patch in locally, merge with my one and
> > > > then
> > > > update my patch on 200.
> > > >
> > > > or
> > > >
> > > > do you want to take the patch I have put on 200 (serverbuild2.patch)
> > > > and
> > > > merge with yours.
> > > >
> > > > If you take SocialApiGuiceModule, then I have no mv or cp operations,
> > > > so I
> > > > might be easier that way round as you have commit.
> > > >
> > > > I'm Ok either way.... except its getting close to kids bedtime GMT,
> so
> > > > I
> > > > will soon go offline for a few hours.
> > > >
> > > > Ian
> > > >
> > > >
> > > >
> > > >
> > > > On 16 Apr 2008, at 17:21, Cassie wrote:
> > > >
> > > > Yeah, I saw these too and fixed them in the patch I attached to
> > > > > SHINDIG-200.
> > > > >
> > > > > I ended up making a new SocialApiGuiceModule for the social
> specific
> > > > > guice
> > > > > stuff and moving a bunch of files into common.
> > > > >
> > > > > - Cassie
> > > > >
> > > > >
> > > > > On Wed, Apr 16, 2008 at 5:49 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> > > > >
> > > > > I am finding some build problems, Ok to fix in my patch ?
> > > > >
> > > > > >
> > > > > > 1. The shared dependency of GadgetDataHandler in both gasdget and
> > > > > > social
> > > > > > 2. The DefaultGuiceModule that needs to be split.
> > > > > >
> > > > > > If ok I am going to move to common. I will keep a list of svn
> > > > > > commands.
> > > > > >
> > > > > >
> > > > > > Ian
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 16 Apr 2008, at 12:30, Cassie wrote:
> > > > > >
> > > > > > Alright Ian - my change is in, so let's make yours work.
> > > > > >
> > > > > > >
> > > > > > > Should we pull out a java/common directory that both gadgets
> and
> > > > > > > the
> > > > > > > social-api poms depend on? We could check in an empty directory
> > > > > > > for
> > > > > > > now just as a place holder so that we can get the structure
> > > > > > > right.
> > > > > > >
> > > > > > > As for the resources:
> > > > > > > - features = gadgets server
> > > > > > > - config = gadgets server
> > > > > > > - javascript = a joint server which has both gadgets and
> > > > > > > social-api
> > > > > > > running?
> > > > > > >
> > > > > > > I think that is close to what we may want...
> > > > > > >
> > > > > > > - Cassie
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk>
> > > > > > > wrote:
> > > > > > >
> > > > > > > Done
> > > > > > >
> > > > > > > > https://issues.apache.org/jira/browse/SHINDIG-200
> > > > > > > >
> > > > > > > > Its not complete since it needs the changes from 199, and
> also
> > > > > > > > needs
> > > > > > > > clarification on which resources are part of which server
> (the
> > > > > > > > javascript
> > > > > > > > files etc)
> > > > > > > >
> > > > > > > > It will run using jetty:run, but the only drawback is that
> now
> > > > > > > > that the
> > > > > > > > wars
> > > > > > > > are overlaid, it takes a mvn compile (in a separate window)
> to
> > > > > > > > get the
> > > > > > > > files
> > > > > > > > into a place where jetty will notice they have changed.
> > > > > > > >
> > > > > > > > Ian
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 16 Apr 2008, at 01:51, David Primmer wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > Sound good. Looking forward to the patch.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <
> > > > > > > > > etnu@google.com> wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > +1 -- I like this a lot, even if it is slightly more
> > > > > > > > > > complex.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Apr 15, 2008 at 5:13 PM, Ian Boston <
> > > > > > > > > > ieb@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 <
> > > > > > > > > > > ieb@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
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 15 Apr 2008, at 17:08, Cassie wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > >
> > > > > > > > > > > > ~Kevin
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > ~Kevin
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
>
>
> --
> ~Kevin
>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Kevin Brown <et...@google.com>.
I don't think the resource files are necessary to achieve this. There's no
reason to have the web resources published statically anywhere but in the
webapp (the war), so therefore that's the only thing that needs to worry
about it. The other resources are common to all language implementations,
and should be pulled in by the appropriate artifacts using relative paths as
they are currently.
On Thu, Apr 17, 2008 at 2:00 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> Cassie,
>
> Sorry for the delay in responding, been in local project planing/panic
> mode today :)
>
> social-api and gadgets pack into jars, that end up as dependencies in
> WEB-INF/lib when the final war is built. The things that need to be on the
> classpath are in those files.
>
> social-api-resources and gadgets-resources contain the files we want
> exposed in the webapp, so they need to be wars (or perhaps zips). When they
> are pulled in in the build of the final war they are overlayed.
>
> Unfortunately this generates lots of artifacts and poms, 6 (3 jars, 2
> overlay wars, 1 target war).
>
> We cant put the contents of the overlay wars into the jars, because they
> a) are not part of the classpath b) probably dont make sense being
> overlayed.
>
> We could put both resource builds into the target war build (server.war),
> but then they would not end up in the maven repo, and so it would not be
> possible for 3rd parties to generate a war from the maven repo.
>
> We could merge the overlay wars into 1 war, but then we would end up with
> all the social files in a gadget server (and visa versa)
>
> So..... I think the 3 jars, 2 overlays and one target offers flexibility,
> while keeping the build automated..... but I am always open to suggestions.
>
>
> The conf directory in social-api and gadgets contains the Guice properties
> file for each respective Module (eg gadgets.properties and
> social.properties), that needs to be in the classpath, and hence is packed
> with the Jar. I think I am right in saying that if someone wanted to provide
> their own set of properties, a file ending up in WEB-INF/classes would take
> precedence when the classloader performs the resolution.
>
> You may be using a name other than social.properites.
>
> I hope that makes sense, if it doesn't, its almost certainly my poor
> explanation, so please ask questions.
>
> Ian
>
>
>
>
> On 17 Apr 2008, at 16:07, Cassie wrote:
>
> > Alright, Ian I grabbed most of the easy stuff in your patch and I think
> > I'm
> > getting a better idea of what the rest of it does. Just one quick
> > question
> > though - do we really need to separate out the *-resources projects from
> > the
> > java/gadgets and java/social-api poms? If we add in everything in the
> > patch
> > we will end up with 6 sub directories, and 8 total pom files :( If we
> > can
> > package the resources up with the servers themselves then at least we
> > are
> > back down to 4 modules.
> >
> > Aside from that it looks good although I don't understand what the new
> > conf
> > directory is in the social and gadgets pom files:
> > + <resources>
> > + <resource>
> > + <directory>conf</directory>
> > + </resource>
> > + </resources>
> >
> > Thanks for bearing with my naiveté!
> >
> > - Cassie
> >
> >
> >
> >
> > On Wed, Apr 16, 2008 at 7:00 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> >
> > Ok,
> > > I've updated the patch on 200,
> > >
> > >
> > > do you want me to pull your patch in locally, merge with my one and
> > > then
> > > update my patch on 200.
> > >
> > > or
> > >
> > > do you want to take the patch I have put on 200 (serverbuild2.patch)
> > > and
> > > merge with yours.
> > >
> > > If you take SocialApiGuiceModule, then I have no mv or cp operations,
> > > so I
> > > might be easier that way round as you have commit.
> > >
> > > I'm Ok either way.... except its getting close to kids bedtime GMT, so
> > > I
> > > will soon go offline for a few hours.
> > >
> > > Ian
> > >
> > >
> > >
> > >
> > > On 16 Apr 2008, at 17:21, Cassie wrote:
> > >
> > > Yeah, I saw these too and fixed them in the patch I attached to
> > > > SHINDIG-200.
> > > >
> > > > I ended up making a new SocialApiGuiceModule for the social specific
> > > > guice
> > > > stuff and moving a bunch of files into common.
> > > >
> > > > - Cassie
> > > >
> > > >
> > > > On Wed, Apr 16, 2008 at 5:49 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> > > >
> > > > I am finding some build problems, Ok to fix in my patch ?
> > > >
> > > > >
> > > > > 1. The shared dependency of GadgetDataHandler in both gasdget and
> > > > > social
> > > > > 2. The DefaultGuiceModule that needs to be split.
> > > > >
> > > > > If ok I am going to move to common. I will keep a list of svn
> > > > > commands.
> > > > >
> > > > >
> > > > > Ian
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 16 Apr 2008, at 12:30, Cassie wrote:
> > > > >
> > > > > Alright Ian - my change is in, so let's make yours work.
> > > > >
> > > > > >
> > > > > > Should we pull out a java/common directory that both gadgets and
> > > > > > the
> > > > > > social-api poms depend on? We could check in an empty directory
> > > > > > for
> > > > > > now just as a place holder so that we can get the structure
> > > > > > right.
> > > > > >
> > > > > > As for the resources:
> > > > > > - features = gadgets server
> > > > > > - config = gadgets server
> > > > > > - javascript = a joint server which has both gadgets and
> > > > > > social-api
> > > > > > running?
> > > > > >
> > > > > > I think that is close to what we may want...
> > > > > >
> > > > > > - Cassie
> > > > > >
> > > > > >
> > > > > > On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk>
> > > > > > wrote:
> > > > > >
> > > > > > Done
> > > > > >
> > > > > > > https://issues.apache.org/jira/browse/SHINDIG-200
> > > > > > >
> > > > > > > Its not complete since it needs the changes from 199, and also
> > > > > > > needs
> > > > > > > clarification on which resources are part of which server (the
> > > > > > > javascript
> > > > > > > files etc)
> > > > > > >
> > > > > > > It will run using jetty:run, but the only drawback is that now
> > > > > > > that the
> > > > > > > wars
> > > > > > > are overlaid, it takes a mvn compile (in a separate window) to
> > > > > > > get the
> > > > > > > files
> > > > > > > into a place where jetty will notice they have changed.
> > > > > > >
> > > > > > > Ian
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 16 Apr 2008, at 01:51, David Primmer wrote:
> > > > > > >
> > > > > > >
> > > > > > > Sound good. Looking forward to the patch.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <
> > > > > > > > etnu@google.com> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > +1 -- I like this a lot, even if it is slightly more
> > > > > > > > > complex.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Apr 15, 2008 at 5:13 PM, Ian Boston <
> > > > > > > > > ieb@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 <
> > > > > > > > > > ieb@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
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On 15 Apr 2008, at 17:08, Cassie wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > 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
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > >
> > > > > > > > > > > ~Kevin
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > ~Kevin
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
>
--
~Kevin
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Ian Boston <ie...@tfd.co.uk>.
Cassie,
Sorry for the delay in responding, been in local project planing/
panic mode today :)
social-api and gadgets pack into jars, that end up as dependencies in
WEB-INF/lib when the final war is built. The things that need to be
on the classpath are in those files.
social-api-resources and gadgets-resources contain the files we want
exposed in the webapp, so they need to be wars (or perhaps zips).
When they are pulled in in the build of the final war they are
overlayed.
Unfortunately this generates lots of artifacts and poms, 6 (3 jars, 2
overlay wars, 1 target war).
We cant put the contents of the overlay wars into the jars, because
they a) are not part of the classpath b) probably dont make sense
being overlayed.
We could put both resource builds into the target war build
(server.war), but then they would not end up in the maven repo, and
so it would not be possible for 3rd parties to generate a war from
the maven repo.
We could merge the overlay wars into 1 war, but then we would end up
with all the social files in a gadget server (and visa versa)
So..... I think the 3 jars, 2 overlays and one target offers
flexibility, while keeping the build automated..... but I am always
open to suggestions.
The conf directory in social-api and gadgets contains the Guice
properties file for each respective Module (eg gadgets.properties and
social.properties), that needs to be in the classpath, and hence is
packed with the Jar. I think I am right in saying that if someone
wanted to provide their own set of properties, a file ending up in
WEB-INF/classes would take precedence when the classloader performs
the resolution.
You may be using a name other than social.properites.
I hope that makes sense, if it doesn't, its almost certainly my poor
explanation, so please ask questions.
Ian
On 17 Apr 2008, at 16:07, Cassie wrote:
> Alright, Ian I grabbed most of the easy stuff in your patch and I
> think I'm
> getting a better idea of what the rest of it does. Just one quick
> question
> though - do we really need to separate out the *-resources projects
> from the
> java/gadgets and java/social-api poms? If we add in everything in
> the patch
> we will end up with 6 sub directories, and 8 total pom files :( If
> we can
> package the resources up with the servers themselves then at least
> we are
> back down to 4 modules.
>
> Aside from that it looks good although I don't understand what the
> new conf
> directory is in the social and gadgets pom files:
> + <resources>
> + <resource>
> + <directory>conf</directory>
> + </resource>
> + </resources>
>
> Thanks for bearing with my naiveté!
>
> - Cassie
>
>
>
>
> On Wed, Apr 16, 2008 at 7:00 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>
>> Ok,
>> I've updated the patch on 200,
>>
>>
>> do you want me to pull your patch in locally, merge with my one
>> and then
>> update my patch on 200.
>>
>> or
>>
>> do you want to take the patch I have put on 200
>> (serverbuild2.patch) and
>> merge with yours.
>>
>> If you take SocialApiGuiceModule, then I have no mv or cp
>> operations, so I
>> might be easier that way round as you have commit.
>>
>> I'm Ok either way.... except its getting close to kids bedtime
>> GMT, so I
>> will soon go offline for a few hours.
>>
>> Ian
>>
>>
>>
>>
>> On 16 Apr 2008, at 17:21, Cassie wrote:
>>
>>> Yeah, I saw these too and fixed them in the patch I attached to
>>> SHINDIG-200.
>>>
>>> I ended up making a new SocialApiGuiceModule for the social
>>> specific guice
>>> stuff and moving a bunch of files into common.
>>>
>>> - Cassie
>>>
>>>
>>> On Wed, Apr 16, 2008 at 5:49 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>
>>> I am finding some build problems, Ok to fix in my patch ?
>>>>
>>>> 1. The shared dependency of GadgetDataHandler in both gasdget
>>>> and social
>>>> 2. The DefaultGuiceModule that needs to be split.
>>>>
>>>> If ok I am going to move to common. I will keep a list of svn
>>>> commands.
>>>>
>>>>
>>>> Ian
>>>>
>>>>
>>>>
>>>>
>>>> On 16 Apr 2008, at 12:30, Cassie wrote:
>>>>
>>>> Alright Ian - my change is in, so let's make yours work.
>>>>>
>>>>> Should we pull out a java/common directory that both gadgets
>>>>> and the
>>>>> social-api poms depend on? We could check in an empty directory
>>>>> for
>>>>> now just as a place holder so that we can get the structure right.
>>>>>
>>>>> As for the resources:
>>>>> - features = gadgets server
>>>>> - config = gadgets server
>>>>> - javascript = a joint server which has both gadgets and social-
>>>>> api
>>>>> running?
>>>>>
>>>>> I think that is close to what we may want...
>>>>>
>>>>> - Cassie
>>>>>
>>>>>
>>>>> On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk>
>>>>> wrote:
>>>>>
>>>>> Done
>>>>>> https://issues.apache.org/jira/browse/SHINDIG-200
>>>>>>
>>>>>> Its not complete since it needs the changes from 199, and also
>>>>>> needs
>>>>>> clarification on which resources are part of which server (the
>>>>>> javascript
>>>>>> files etc)
>>>>>>
>>>>>> It will run using jetty:run, but the only drawback is that now
>>>>>> that the
>>>>>> wars
>>>>>> are overlaid, it takes a mvn compile (in a separate window) to
>>>>>> get the
>>>>>> files
>>>>>> into a place where jetty will notice they have changed.
>>>>>>
>>>>>> Ian
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 16 Apr 2008, at 01:51, David Primmer wrote:
>>>>>>
>>>>>>
>>>>>>> Sound good. Looking forward to the patch.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown
>>>>>>> <et...@google.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> +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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 15 Apr 2008, at 17:08, Cassie wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>> ~Kevin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> ~Kevin
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Cassie <do...@google.com>.
Alright, Ian I grabbed most of the easy stuff in your patch and I think I'm
getting a better idea of what the rest of it does. Just one quick question
though - do we really need to separate out the *-resources projects from the
java/gadgets and java/social-api poms? If we add in everything in the patch
we will end up with 6 sub directories, and 8 total pom files :( If we can
package the resources up with the servers themselves then at least we are
back down to 4 modules.
Aside from that it looks good although I don't understand what the new conf
directory is in the social and gadgets pom files:
+ <resources>
+ <resource>
+ <directory>conf</directory>
+ </resource>
+ </resources>
Thanks for bearing with my naiveté!
- Cassie
On Wed, Apr 16, 2008 at 7:00 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> Ok,
> I've updated the patch on 200,
>
>
> do you want me to pull your patch in locally, merge with my one and then
> update my patch on 200.
>
> or
>
> do you want to take the patch I have put on 200 (serverbuild2.patch) and
> merge with yours.
>
> If you take SocialApiGuiceModule, then I have no mv or cp operations, so I
> might be easier that way round as you have commit.
>
> I'm Ok either way.... except its getting close to kids bedtime GMT, so I
> will soon go offline for a few hours.
>
> Ian
>
>
>
>
> On 16 Apr 2008, at 17:21, Cassie wrote:
>
>> Yeah, I saw these too and fixed them in the patch I attached to
>> SHINDIG-200.
>>
>> I ended up making a new SocialApiGuiceModule for the social specific guice
>> stuff and moving a bunch of files into common.
>>
>> - Cassie
>>
>>
>> On Wed, Apr 16, 2008 at 5:49 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>> I am finding some build problems, Ok to fix in my patch ?
>>>
>>> 1. The shared dependency of GadgetDataHandler in both gasdget and social
>>> 2. The DefaultGuiceModule that needs to be split.
>>>
>>> If ok I am going to move to common. I will keep a list of svn commands.
>>>
>>>
>>> Ian
>>>
>>>
>>>
>>>
>>> On 16 Apr 2008, at 12:30, Cassie wrote:
>>>
>>> Alright Ian - my change is in, so let's make yours work.
>>>>
>>>> Should we pull out a java/common directory that both gadgets and the
>>>> social-api poms depend on? We could check in an empty directory for
>>>> now just as a place holder so that we can get the structure right.
>>>>
>>>> As for the resources:
>>>> - features = gadgets server
>>>> - config = gadgets server
>>>> - javascript = a joint server which has both gadgets and social-api
>>>> running?
>>>>
>>>> I think that is close to what we may want...
>>>>
>>>> - Cassie
>>>>
>>>>
>>>> On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>
>>>> Done
>>>>> https://issues.apache.org/jira/browse/SHINDIG-200
>>>>>
>>>>> Its not complete since it needs the changes from 199, and also needs
>>>>> clarification on which resources are part of which server (the
>>>>> javascript
>>>>> files etc)
>>>>>
>>>>> It will run using jetty:run, but the only drawback is that now that the
>>>>> wars
>>>>> are overlaid, it takes a mvn compile (in a separate window) to get the
>>>>> files
>>>>> into a place where jetty will notice they have changed.
>>>>>
>>>>> Ian
>>>>>
>>>>>
>>>>>
>>>>> On 16 Apr 2008, at 01:51, David Primmer wrote:
>>>>>
>>>>>
>>>>>> Sound good. Looking forward to the patch.
>>>>>>
>>>>>>
>>>>>> On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <et...@google.com> wrote:
>>>>>>
>>>>>>
>>>>>>> +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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 15 Apr 2008, at 17:08, Cassie wrote:
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>> ~Kevin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> ~Kevin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Ian Boston <ie...@tfd.co.uk>.
Ok,
I've updated the patch on 200,
do you want me to pull your patch in locally, merge with my one and
then update my patch on 200.
or
do you want to take the patch I have put on 200 (serverbuild2.patch)
and merge with yours.
If you take SocialApiGuiceModule, then I have no mv or cp operations,
so I might be easier that way round as you have commit.
I'm Ok either way.... except its getting close to kids bedtime GMT,
so I will soon go offline for a few hours.
Ian
On 16 Apr 2008, at 17:21, Cassie wrote:
> Yeah, I saw these too and fixed them in the patch I attached to
> SHINDIG-200.
>
> I ended up making a new SocialApiGuiceModule for the social
> specific guice
> stuff and moving a bunch of files into common.
>
> - Cassie
>
>
> On Wed, Apr 16, 2008 at 5:49 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>
>> I am finding some build problems, Ok to fix in my patch ?
>>
>> 1. The shared dependency of GadgetDataHandler in both gasdget and
>> social
>> 2. The DefaultGuiceModule that needs to be split.
>>
>> If ok I am going to move to common. I will keep a list of svn
>> commands.
>>
>>
>> Ian
>>
>>
>>
>>
>> On 16 Apr 2008, at 12:30, Cassie wrote:
>>
>>> Alright Ian - my change is in, so let's make yours work.
>>>
>>> Should we pull out a java/common directory that both gadgets and the
>>> social-api poms depend on? We could check in an empty directory for
>>> now just as a place holder so that we can get the structure right.
>>>
>>> As for the resources:
>>> - features = gadgets server
>>> - config = gadgets server
>>> - javascript = a joint server which has both gadgets and social-api
>>> running?
>>>
>>> I think that is close to what we may want...
>>>
>>> - Cassie
>>>
>>>
>>> On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>
>>>> Done
>>>> https://issues.apache.org/jira/browse/SHINDIG-200
>>>>
>>>> Its not complete since it needs the changes from 199, and also
>>>> needs
>>>> clarification on which resources are part of which server (the
>>>> javascript
>>>> files etc)
>>>>
>>>> It will run using jetty:run, but the only drawback is that now
>>>> that the
>>>> wars
>>>> are overlaid, it takes a mvn compile (in a separate window) to
>>>> get the
>>>> files
>>>> into a place where jetty will notice they have changed.
>>>>
>>>> Ian
>>>>
>>>>
>>>>
>>>> On 16 Apr 2008, at 01:51, David Primmer wrote:
>>>>
>>>>>
>>>>> Sound good. Looking forward to the patch.
>>>>>
>>>>>
>>>>> On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <et...@google.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> +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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 15 Apr 2008, at 17:08, Cassie wrote:
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> ~Kevin
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ~Kevin
>>>>>>
>>>>>>
>>>>
>>>>
>>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Cassie <do...@google.com>.
Yeah, I saw these too and fixed them in the patch I attached to SHINDIG-200.
I ended up making a new SocialApiGuiceModule for the social specific guice
stuff and moving a bunch of files into common.
- Cassie
On Wed, Apr 16, 2008 at 5:49 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> I am finding some build problems, Ok to fix in my patch ?
>
> 1. The shared dependency of GadgetDataHandler in both gasdget and social
> 2. The DefaultGuiceModule that needs to be split.
>
> If ok I am going to move to common. I will keep a list of svn commands.
>
>
> Ian
>
>
>
>
> On 16 Apr 2008, at 12:30, Cassie wrote:
>
>> Alright Ian - my change is in, so let's make yours work.
>>
>> Should we pull out a java/common directory that both gadgets and the
>> social-api poms depend on? We could check in an empty directory for
>> now just as a place holder so that we can get the structure right.
>>
>> As for the resources:
>> - features = gadgets server
>> - config = gadgets server
>> - javascript = a joint server which has both gadgets and social-api
>> running?
>>
>> I think that is close to what we may want...
>>
>> - Cassie
>>
>>
>> On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>>> Done
>>> https://issues.apache.org/jira/browse/SHINDIG-200
>>>
>>> Its not complete since it needs the changes from 199, and also needs
>>> clarification on which resources are part of which server (the javascript
>>> files etc)
>>>
>>> It will run using jetty:run, but the only drawback is that now that the
>>> wars
>>> are overlaid, it takes a mvn compile (in a separate window) to get the
>>> files
>>> into a place where jetty will notice they have changed.
>>>
>>> Ian
>>>
>>>
>>>
>>> On 16 Apr 2008, at 01:51, David Primmer wrote:
>>>
>>>>
>>>> Sound good. Looking forward to the patch.
>>>>
>>>>
>>>> On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <et...@google.com> wrote:
>>>>
>>>>>
>>>>> +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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 15 Apr 2008, at 17:08, Cassie wrote:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> ~Kevin
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> ~Kevin
>>>>>
>>>>>
>>>
>>>
>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Ian Boston <ie...@tfd.co.uk>.
I am finding some build problems, Ok to fix in my patch ?
1. The shared dependency of GadgetDataHandler in both gasdget and social
2. The DefaultGuiceModule that needs to be split.
If ok I am going to move to common. I will keep a list of svn commands.
Ian
On 16 Apr 2008, at 12:30, Cassie wrote:
> Alright Ian - my change is in, so let's make yours work.
>
> Should we pull out a java/common directory that both gadgets and the
> social-api poms depend on? We could check in an empty directory for
> now just as a place holder so that we can get the structure right.
>
> As for the resources:
> - features = gadgets server
> - config = gadgets server
> - javascript = a joint server which has both gadgets and social-api
> running?
>
> I think that is close to what we may want...
>
> - Cassie
>
>
> On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>> Done
>> https://issues.apache.org/jira/browse/SHINDIG-200
>>
>> Its not complete since it needs the changes from 199, and also needs
>> clarification on which resources are part of which server (the
>> javascript
>> files etc)
>>
>> It will run using jetty:run, but the only drawback is that now
>> that the wars
>> are overlaid, it takes a mvn compile (in a separate window) to get
>> the files
>> into a place where jetty will notice they have changed.
>>
>> Ian
>>
>>
>>
>> On 16 Apr 2008, at 01:51, David Primmer wrote:
>>>
>>> Sound good. Looking forward to the patch.
>>>
>>>
>>> On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <et...@google.com>
>>> wrote:
>>>>
>>>> +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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 15 Apr 2008, at 17:08, Cassie wrote:
>>>>>>>
>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ~Kevin
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ~Kevin
>>>>
>>
>>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Ian Boston <ie...@tfd.co.uk>.
On 16 Apr 2008, at 12:30, Cassie wrote:
> Alright Ian - my change is in, so let's make yours work.
>
> Should we pull out a java/common directory that both gadgets and the
> social-api poms depend on? We could check in an empty directory for
> now just as a place holder so that we can get the structure right.
Yes that makes sense, even if it results in an empty jar, we have the
placeholder and the plumbing.
>
> As for the resources:
> - features = gadgets server
> - config = gadgets server
> - javascript = a joint server which has both gadgets and social-api
> running?
Ok, I will give that a go.
>
> I think that is close to what we may want...
>
> - Cassie
>
>
--snip--
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Cassie <do...@google.com>.
Alright Ian - my change is in, so let's make yours work.
Should we pull out a java/common directory that both gadgets and the
social-api poms depend on? We could check in an empty directory for
now just as a place holder so that we can get the structure right.
As for the resources:
- features = gadgets server
- config = gadgets server
- javascript = a joint server which has both gadgets and social-api running?
I think that is close to what we may want...
- Cassie
On Wed, Apr 16, 2008 at 12:13 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> Done
> https://issues.apache.org/jira/browse/SHINDIG-200
>
> Its not complete since it needs the changes from 199, and also needs
> clarification on which resources are part of which server (the javascript
> files etc)
>
> It will run using jetty:run, but the only drawback is that now that the wars
> are overlaid, it takes a mvn compile (in a separate window) to get the files
> into a place where jetty will notice they have changed.
>
> Ian
>
>
>
> On 16 Apr 2008, at 01:51, David Primmer wrote:
>>
>> Sound good. Looking forward to the patch.
>>
>>
>> On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <et...@google.com> wrote:
>>>
>>> +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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 15 Apr 2008, at 17:08, Cassie wrote:
>>>>>>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> ~Kevin
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> ~Kevin
>>>
>
>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Ian Boston <ie...@tfd.co.uk>.
Done
https://issues.apache.org/jira/browse/SHINDIG-200
Its not complete since it needs the changes from 199, and also needs
clarification on which resources are part of which server (the
javascript files etc)
It will run using jetty:run, but the only drawback is that now that
the wars are overlaid, it takes a mvn compile (in a separate window)
to get the files into a place where jetty will notice they have changed.
Ian
On 16 Apr 2008, at 01:51, David Primmer wrote:
> Sound good. Looking forward to the patch.
>
>
> On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <et...@google.com> wrote:
>> +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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 15 Apr 2008, at 17:08, Cassie wrote:
>>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> ~Kevin
>>>>
>>>
>>>
>>
>>
>> --
>> ~Kevin
>>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Cassie <do...@apache.org>.
Okay, I'll check in my thing cause I have no idea how the heck to do
that, and then Ian can make a patch to fix it better. At least my
thing gets all the silly file moves out of the way.
Sounds perfect :)
- Cassie
On Wed, Apr 16, 2008 at 2:51 AM, David Primmer <da...@gmail.com> wrote:
> Sound good. Looking forward to the patch.
>
>
> On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <et...@google.com> wrote:
>> +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
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On 15 Apr 2008, at 17:08, Cassie wrote:
>> > > >
>> > > > 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
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> > > --
>> > > ~Kevin
>> > >
>> >
>> >
>>
>>
>> --
>> ~Kevin
>>
>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by David Primmer <da...@gmail.com>.
Sound good. Looking forward to the patch.
On Tue, Apr 15, 2008 at 5:42 PM, Kevin Brown <et...@google.com> wrote:
> +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
> > > >
> > > >
> > > >
> > > >
> > > > On 15 Apr 2008, at 17:08, Cassie wrote:
> > > >
> > > > 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > > --
> > > ~Kevin
> > >
> >
> >
>
>
> --
> ~Kevin
>
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Kevin Brown <et...@google.com>.
+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
> > >
> > >
> > >
> > >
> > > On 15 Apr 2008, at 17:08, Cassie wrote:
> > >
> > > 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
> > > >
> > > >
> > >
> > >
> >
> > --
> > ~Kevin
> >
>
>
--
~Kevin
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Ian Boston <ie...@tfd.co.uk>.
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
>>
>>
>>
>>
>> On 15 Apr 2008, at 17:08, Cassie wrote:
>>
>>> 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
>>>
>>
>>
>
>
> --
> ~Kevin
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Kevin Brown <et...@google.com>.
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
>
>
>
>
> On 15 Apr 2008, at 17:08, Cassie wrote:
>
> > 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
> >
>
>
--
~Kevin
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Ian Boston <ie...@tfd.co.uk>.
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.
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.
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)
Ian
On 15 Apr 2008, at 17:08, Cassie wrote:
> 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
Re: Getting the socialdata servlet and friends into java/social-api
Posted by Kevin Brown <et...@google.com>.
Looks good to me. We can always apply more patches if anything goes wrong :)
On Tue, Apr 15, 2008 at 9:08 AM, Cassie <do...@apache.org> wrote:
> 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
>
--
~Kevin
Re: Getting the socialdata servlet and friends into java/social-api
Posted by David Primmer <da...@gmail.com>.
Thanks Cassie!!! We really needed this. I'm getting the changes now. I
like root web.xml to tie together the servlets.
davep
On Tue, Apr 15, 2008 at 9:08 AM, Cassie <do...@apache.org> wrote:
> 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
>