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 >
