I said to do exactly what you did :)

On Fri, Apr 18, 2008 at 1:57 AM, Cassie <[EMAIL PROTECTED]> 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
> >
>



-- 
~Kevin

Reply via email to