[
https://issues.apache.org/jira/browse/SHINDIG-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590126#action_12590126
]
Kevin Brown commented on SHINDIG-200:
-------------------------------------
You're right -- in the short term it doesn't require those files to be
modified.
But it still shouldn't be moved -- "GadgetException" is what gadget-related
stuff throws. It doesn't make any sense for something in common (or social-api)
to throw a "GadgetException", does it? A new exception type would be much more
appropriate.
> Patch to construct server from jars and war overlays
> ----------------------------------------------------
>
> Key: SHINDIG-200
> URL: https://issues.apache.org/jira/browse/SHINDIG-200
> Project: Shindig
> Issue Type: Improvement
> Reporter: Ian Boston
> Attachments: create_java_common_without_file_moves.patch,
> serverbuild3.patch
>
>
> From the list:
> +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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
