Enclosed: POM fragment that gets Maven to play nice with GWT 1.6.4
After a day or so playing around I have made a Maven pom.xml that
respects the directory structure output by the webappCreator tool.
Here are the relevant bits. Again, for veteran Maven users, rather
than try to make the GWT Eclipse Plugin respect a tried-and-true maven
layout, which I've read on this group is kind of tough if not
impossible, I went the other way around. That means that you will NOT
see a src/main/java directory, and the war source directory will also
be used as the target (that's how the GWT tools do it).
Another way to put it is that I followed the advice of the plugin
authors who said when in doubt try to make your custom build tooling
do what the base ant build.xml does.
Lastly, this POM fragment uses the Codehaus gwt-maven-plugin, so if
you run:
mvn package
...you'll get your war file in the good old target directory (where it
should be, of course) and your in-place war in the war directory.
This should allow Eclipse folks to work normally, as well as hosted
mode.
I hope this helps someone; it took WAY too long to do this.
As of today, April 22, the only known issue is that the gwt-maven-
plugin will "see" your module twice (you can configure it to only look
for specific modules and can avoid this; I didn't). That means at the
moment that at package time you'll run the resource-hoggy GWT compiler
twice. :-( I think that bug will probably be fixed very soon, so I
didn't choose to work around it in this pom fragment.
com.google.gwt
gwt-servlet
${gwt.version}
runtime
com.google.gwt
gwt-user
${gwt.version}
provided
src
test
war/WEB-INF/classes
${project.build.sourceDirectory}
**/*.java
org.apache.maven.plugins
maven-resources-plugin
utf-8
org.apache.maven.plugins
maven-war-plugin
LATEST
${basedir}/war
**
${basedir}/war
${basedir}/war/WEB-INF/web.xml
org.codehaus.mojo
gwt-maven-plugin
1.1-SNAPSHOT
compile
path.to.your.Module/../Module.html
${basedir}/war
${basedir}/war/WEB-INF/web.xml
${basedir}/war
Codehaus
http://snapshots.repository.codehaus.org
false
true
1.6.4
I hope this helps.
Best,
Laird
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Enclosed: POM fragment that gets Maven to play nice with GWT 1.6.4
On Thu, Apr 23, 2009 at 3:50 AM, Salvador Diaz wrote: > Unfortunately this pom has the undesirable side effect of polluting > your source tree with generated artifacts. I'll try to post mine as > soon as I have time to comment it. > Oh, absolutely agreed. That's the way the build.xml does it, though, and I've got a lot of Eclipse users who want to follow the Eclipse plugin recommendations. Here's the stock build.xml barfed out by webappCreator, complete with various hard coded paths. My goal was to make it so that maven and this thing could coexist: I'd be very curious to see your POM as *I* personally don't want to have my source tree polluted, and I don't use Eclipse. Cheers, Laird --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Best practices?
I'm looking for some recommendations from the hard-core GWT users out
there. I'm sure my requirements are not unique.
What is the best way to set up a modular web application that features
GWT?
There, that's the one-sentence question in case this has been answered
many times before--so do please feel free to point me somewhere else.
Bear in mind general web-application organizational principles are
heartily welcomed as well--that is, GWT may not really be terribly
relevant here, but it seems like its organizational principles would
constrain any solution.
A little more background:
The application I'm working on is actually many applications. Prior
to this new direction, each application was in charge, fully, of its
own UI. We're heading down a path where really what we want is for
each application to be "housed" in a common "housing". The housing
would be in charge of governing the navigation between areas of the
overall application. So it's sort of like portlets, but without the
baggage that implies--the "housed" applications wouldn't look like
little windows, and there wouldn't be lots of them on the page;
probably only one or two.
What I'd like to do in a vacuum is {handwave handwave} make a bunch of
web applications, one per "portlet", and then also {handwave handwave}
make the housing web application as well, and somehow merge them
together or otherwise cause the housing to pull in the parts.
I'd also like those parts to be standalone, so that, for example, I
could build an individual war file and test it standalone, knowing
that I'd be giving up navigation and other services provided by the
housing, and that the UI provided by the "part" would obviously be
devoid of common elements (like headers, navbars, footers and the
like).
What I don't want to do, unless I simply don't have a choice, is to
have one giant .war file that represents my whole application. I've
worked with that model before at a large financial institution, and
it's just cumbersome and unwieldy. I'm hoping that there's some
clever solution out there I haven't thought of whereby several web
applications could be "joined" together by the "housing" part, i.e.
you would launch the (skinny) housing application, and it would
{handwave handwave} pull in content sourced from other web
applications (or, from its perspective, I guess, simple URLs).
(In case it matters, I'm using Maven and the gwt-maven-plugin, but
I've got that working so that it works with the existing project
structure that GWT requires. I mention this because Maven has support
for .war file overlays which may come in handy here--where at compile
time you are able to mix together two or more .war files into a sort
of composite war file.)
Thanks for your patience if you've read this far, and I'm looking
forward to the recommendations that are sure to follow.
Best,
Laird
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Best practices?
On Apr 23, 1:04 pm, Jeff Chimene wrote: > You're asking two questions: At least. :-D > You've already said you don't want to "... have one giant .war file > that represents my whole application...". In GWT, I'd use multiple > applications, each with its own entry point. Apply generous amounts of > JUnit. So--just so I'm clear--five .war files, five Eclipse projects, etc.? Each of which would feature at least one entry point? How are you suggesting I should pull these entry points together under the "housing"? That's where I'm conceptually stuck. Or, conversely, given a housing .war, how should it pull content from other .wars? Now, I'm thick and slow at this stuff so far (early days!) but my understanding is that an entry point is Java-to-Javascript code that is executed when a host HTML page makes reference to the entry point. So if I have an HTML page that refers to 127 entry points, then it's like running 127 main() (onModuleLoad()) methods. So if I want the housing app to pull in the, say, finance application, then somewhere under the control of the housing app there will be an HTML page sucking in the housing module/entry point, and sucking in the finance module/entry point. Now in a perfect world I wouldn't want the housing app to know that it's pulling in the finance app. I come from a rich client development background, primarily, doing stuff on the NetBeans platform. There you can drop your NetBeans modules (.jar files) in The Right Place, and the "housing" (the NetBeans platform) picks them up dynamically and runs them. I'm looking for the GWT analog here. Perhaps another way to ask (one of) my questions is like this: I want one .war to have the HTML files that are in charge of deciding what entry points--from various other .war files--to load. There are two problems with this, which is partly why I feel like I'm groping in the dark, and am reaching out to the GWT group here: 1. War files don't know about other war files. So war file 1 can't go rummaging around in war file 2 to find a GWT module. That's nevertheless sort of what I want to happen. 2. Since that really isn't an option, what's left is the housing referring to something like a list of URLs, each of which talks to a servlet or what-have-you hosted by the "housed" war files. That is, let the Housing GWT app load up in the browser and then kick off a bunch of async requests to go hit various URLs for the sub- applications. Something here just smells fishy to me; I am not articulate enough at the moment to be able to state clearly what my problem is with this approach. Perhaps you or someone else can educate me here. One ancillary thing that occurs to me is that security and authentication is a pain going this route unless there's an SSO server back there somewhere. > GWT gives you the ability to use Java source code management and > testing technology while generating Javascript. I'd leverage that going > forward. You haven't mentioned the server-side code. That may affect > this discussion. True; good point. For now, assume it's pure JEE 5 stuff (.war files, servlets, EJB3 on the back end). We haven't made a final decision on whether to use GWT RPC stuff or go pure web services for our communication with the back end. > o How to crush multiple legacy apps together, still keep them unique, > while leveraging HTML > Frames. Seriously? Yikes. These aren't legacy applications, BTW; they're being developed right now. Best, Laird --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Best practices?
On Thu, Apr 23, 2009 at 3:49 PM, Jeff Chimene wrote: > On 04/23/2009 10:39 AM, Laird Nelson wrote: > > On Apr 23, 1:04�pm, Jeff Chimene wrote: > >> � � �You've already said you don't want to "... have one giant .war file > >> that represents my whole application...". In GWT, I'd use multiple > >> applications, each with its own entry point. Apply generous amounts of > >> JUnit. > > > > So--just so I'm clear--five .war files, five Eclipse projects, etc.? > > If you don't want a monolithic .war, you'll have (WAR count) > 1, no? That's certainly what I thought, but I wasn't sure if it was possible to, for example, split out the "housed" applications into jar files and then glom them all into a war file at war file construction time. > Forget Eclipse projects for the moment. It's a question I didn't ask > (what IDE are you considering?), and deliberately so. > .war files are IDE independent. Using Maven, you can construct .wars in > whatever way suits your deployment strategy. Yes, and that's actually what we're using. Well, or looking to use anyhow. > Remember, .war files are a Java construct shoe-horned into a Javascript > world. They solve a large-ish problem while (perhaps) creating others. > On a server, one doesn't "pull content from other .wars". The content > will be served via your httpd from a directory containing Javascript, > HTML, images, &c. My apologies if you already know this. I do, but no need to apologize. > Perhaps NetBeans is appropriate here? Please read on for further > questions on that point. NetBeans is a Swing-based rich client framework; I think perhaps you have it confused with something else? > > So if I want the > > housing app to pull in the, say, finance application, then somewhere > > under the control of the housing app there will be an HTML page > > sucking in the housing module/entry point, and sucking in the finance > > module/entry point. > > Entry points are one thing. Libraries of application-specific code are > also possible (implemented via Java classes). Right. > > Now in a perfect world I wouldn't want the housing app to know that > > it's pulling in the finance app. I come from a rich client > > development background, primarily, doing stuff on the NetBeans > > platform. There you can drop your NetBeans modules (.jar files) in > > The Right Place, and the "housing" (the NetBeans platform) picks them > > up dynamically and runs them. I'm looking for the GWT analog here. > > I'm probably not a good reference for NetBeans. NetBeans is an > architecture that embraces Javascript and HTML, no? No. :-) No problem. > I think the "GWT analog" is: > o The client makes AJAX requests of the server; > o The server, running in a NetBeans framework, decides which of several > resources can respond to the request; > o Those resources, in the form of raw data, Javascript, HTML, images, &c > are sent to the client; > o The response is transformed using the GWT classes into (D)HTML and > other UI shiny stuff > The reason I'm hung up on the implementation is not because I haven't thought about how the application should behave. If anything, I've thought TOO hard about that, as well as how the applications, plural, should be maintained, developed, versioned, upgraded, customized, and finally aggregated together into different wholes for different clients. One client, for example, may want the finance application only. Another may want the order application and the finance application. Both clients will of necessity need the "housing", since that governs how you navigate around this sick little world. ;-) So it's really more of a packaging question I'm asking than a Help Me To Understand GWT question--the only reason GWT comes into play that I can see is that it appears that GWT is not capable of modularly and dynamically sucking in *code* at runtime that didn't exist before. See, for example, this excellent thread: http://tinyurl.com/cveeft. (Returning briefly to NetBeans for a moment, the whole architecture is built on the fact that it sucks in code dynamically at run time. So the NetBeans "housing" fires up empty, initially, and then scans the classpath or other area to discover the various little-m modules it needs to pull in, and does so. In GWT's case you have to specify those modules up front, i.e. in your HTML host page. If the HTML host page is being served out of a location or package or .war file or other kind of web application hairball that is supposed to be self-contained, by definition it can't know about ot
Re: Best practices?
On Thu, Apr 23, 2009 at 3:55 PM, Ben FS wrote: > Any HTML page can include any number of GWT modules, and for each one > the EntryPoint will be called. And I could have a module without an EntryPoint, as I understand it. > Each GWT module can include both client- > side and server-side components, or only client-side components, or > only server-side components. Additionally, you can have server-side > stuff that is not part of a GWT module. You can have a GWT module that > includes all your core or common elements, and another GWT module that > implements the account management UI and back-end, and another GWT > module that provides a "latest news" feature, and so on for each "sub- > application". Right. > For the "housing": You can write a simple HTML page that includes each > of these modules directly (link to the .js file for the module and > provide a DIV slot for the module). Or you can have such HTML > generated dynamically server-side. OK. > Or you can have one GWT module that > itself includes and arranges other GWT modules (the sub-applications). Perhaps a *really* stupid question, but how do I do that? I didn't realize a GWT module could load another one itself. Sounds like your application is bigger, there are multiple people > working on it, etc. Oh yes. Would that it were smaller. :-) > I'd suggest maintaining a single source tree, with > separate packages for the different modules, and then just let each > developer check out the parts they modify directly into their project. Well, I'd just as soon not have one big .war file that everyone is whacking away on. For one thing, I'd like to use Maven to version the various artifacts. In my dumb example, assume the presence of some sort of housing artifact (.war, probably), the finance app artifact (another .war? something else?), the order app artifact (another .war? something else?) that get pulled together and aggregated into some sort of distribution unit that gets sent off to clients. Each client may get a different distribution unit made up of these building blocks. > To make this work well, you should set up each module to be packaged > into its own JAR file (which is how GWT library modules are > distributed), which then can be included by the developer. Ah, OK. I need to do some more reading; I did not realize that GWT library modules could be distributed as jar files. If I can do that--as in, work in isolation in a corner somewhere, set up a stupid little hosted war environment to test things out with, but then only distribute my end product as a jar file--to be combined together with my other teams' jar files and aggregated together into the final war file--that would probably work well. I'm sure it's in front of me somewhere, but do you have a pointer to get me started on this packaging method? Thanks very much for your time and help; it is greatly appreciated. Best, Laird --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Best practices?
On Apr 23, 8:32 pm, Ben FS wrote: > Let's try a concrete example. Feel free to specify something closer to > what you want. I think you want to have a bunch of applications, each > of which could run on its own, but you also want a "housing" > application that provides navigation, etc. and decides which sub- > applications to include in the UI. Yes? Yes. > One way to do this: > 1. Make a core GWT module. It defines an "Application" abstract class > that inherits from GWT's Composite class. > 2. Make the "housing" GWT module. It provides the high-level UI with > navigation, etc. and placeholders for one or more Application > instances. > 3. Make additional GWT modules, each containing a concrete sub-class > of Application. These are your "sub-applications". They each define an > EntryPoint, useful for testing them on their own, but mainly you will > instantiate each Application as a UI component in the "housing" > application. Yes, that's exactly the model I want from a where-is-the-code- developed-and-how-is-it-organized perspective. The dilemma I'm still facing is: do I go with "loading option" 1 or 2, where the options are described in the page you referenced in your last post (http://code.google.com/webtoolkit/doc/1.6/ DevGuideOrganizingProjects.html#DevGuideModules): 1. Compile each module separately and include each module with a separate tag in your HTML host page. 2. Create a top level module XML definition that includes all the modules you want to include. Compile the top level module to create a single set of JavaScript output. That page strongly recommends #2, but that implies that I would be sucking down what would amount to an entire ERP application into my browser, right? I mean, the Javascript to define what the finance application is would be downloaded by the browser in option 2, along with the Javascript for the housing application, and the Javascript for the order application, and the Javascript for the kitchen sink application and so on, even if the customer spent all his time in the finance application. To make it more concrete, option 2 would have me do this in Housing.gwt.xml: http://google-web-toolkit.googlecode.com/svn/tags/1.6.4/distro- source/core/src/gwt-module.dtd">...and I'd invoke the GWT compiler to assemble one great big hairball of Javascript, which would be included, once, in the housing's HTML: Housing Application