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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
wrote:
Looking at the patch and just having updated from svn, I
think this
means
that
in addition to the patch Cassie is working on....
java/social-api becomes a jar
java/gadget becomes a jar
---------
There is a new project to build a overlay war from features/**
javascript/** config/** ,
perhapse split into 2, one for gadgets and one for social-api
(not
certain
about the split)
eg
java/gadget-resources
java/social-api-resources
These just contain a pom.xml that builds the overlay.
----------------
Then there is a new webapp
java/server
That contains src/main/webapp/WEB-INF/web.xml
that unpacks the overlay wars, pulls in the jars and packages
as a
war...
for running in jetty.
This would not enforce boundaries between social-api and
gadget, but
would
enable both to run, and for others to construct a target.
Perhaps thats too complex and there could be some
simplification.... I
would be happy to generate a patch once Cassie is done....
One other thing. I have found that the maven plugins that
build sites
(less important) and perform releases(more important) are
picky about
the
relationship between the directory name, the artifact ID, how
the
group
ID
changes as the directory structure gets deeper.
If you want to use these plugins in multiproject mode, then it
probably
worth trying them now... just to make certain that they do
work. If
the
entire build is maven2 based, the the release plugin is well
worth the
hassle Changing artifact names and structure later an be a
complete
pain,
see https://source.sakaiproject.org/svn//kernel/trunk/ to see
what I
mean.
Ian
On 16 Apr 2008, at 00:40, Kevin Brown wrote:
On Tue, Apr 15, 2008 at 3:14 PM, Ian Boston <[EMAIL PROTECTED]>
wrote:
One way might be...
add a webapp project that takes a jar from gadgets and a
jar from
social
api and a jar from common and builds the war.
That's what I'm in favor of doing.
It might also overlay wars or zips containing all the
javascript
html
and
css files.. so that in the war project there is just the
web.xml
thatis used
for a sample deployment.
These would belong in there as well, as resources.
Then with the jetty target, run that war.
For those who want to construct their own webapp and perhaps
customize
the
injection of the service layer, they can pull the gadgets
jar, the
social-api jar and the javascript zip/jar/war from the
maven repo
and
merge
with their own webapp project (with a customized web.xml,
service
implementation jar and guice service module)
And that's exactly what I've been asking for. It's exactly
what I
want
to do
for our deployments at google, and I'm sure it's a model
that other
people
would like as well.
Ian
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
