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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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
--
~Kevin
