Hi Sebastien, It's actually fairly compatible, the difference is more in attitude and expectation. You would provide the WEB-INF directory yourself, GWT no longer tries to control everything. The model is more that GWT can plug in easily to existing web apps. For example, you would also want to setup build rules to compile your server-side code into WEB-INF/classes.
Scott On Mon, Feb 9, 2009 at 1:35 AM, Sebastien <[email protected]> wrote: > > Hi, > > I take a look on the build.xml of samples. I didn't see any special > difference. > Here is a part of my build.xml : > <java maxmemory="1200m" classname="com.google.gwt.dev.Compiler" > fork="true" failonerror="true" taskName="gwtc"> > <arg value="com.raisepartner.prism.PRISM" /> > <classpath> > <pathelement location="src/main"/> > <fileset dir="${prj.lib}"><include > name="**/*.jar"/></fileset> > </classpath> > </java> > =====> > [gwtc] Compiling module com.raisepartner.prism.PRISM > [gwtc] Compiling 10 > permutations > [gwtc] Permutation compile > succeeded > [gwtc] Linking into > war > [gwtc] Link > succeeded > [gwtc] Compilation succeeded -- > 483,002s > > The output is 'war' directory at the root of my project. This > directory contains only the module directory. There is no WEB-INF > directory created. Is it the expected behavior ? > By looking the samples I understand that my main html page (the one > calling the nocache.js) must me copied manually at the root of the war > directory. The content of the <module>.public is copied into war/ > <module>. I expected the content would be copied at the root of the > 'war' directory. > > So my conclusion is that there is no change compared to the > 1.5.3 ... :-( > > Regards, > Seb > On 8 fév, 23:45, Dop Sun <[email protected]> wrote: > > I guess in the sample projects (included in the M1 build), there is > > build file for each and every of them, and within that, there build > > tasks for the project. Maybe, you can have a try what there? > > > > On Feb 9, 2:49 am, Sebastien <[email protected]> wrote: > > > > > Hi, > > > > > I am interested to migrate from the 1.5.3 to the 1.6.0 M1. When I use > > > this M1 with -war option, the the compiler output is not like an > > > expanded war. I tried to specify all parameters (-war, -gen, - > > > extra ..) without success. The output of the compiler is always > > > similar to the output of the 1.5.3 compiler. The compiler indicates > > > the 1.6.0 version, so I am sure to use the 1.6. I am under linux > > > (ubuntu). > > > > > Do you have any idea why the compiler output is not like an expanded > > > war ? > > > > > Regards, > > > Seb > > > > > On 6 fév, 16:26, Scott Blum <[email protected]> wrote: > > > > > > Greetings GWT developers, > > > > > > The GWT team is happy to announce the availability of 1.6 Milestone > 1! > > > > Binary distributions are available for download directly from GWT's > Google > > > > Code project. > > > > > > > http://code.google.com/p/google-web-toolkit/downloads/list?can=1&q=1.6.0 > > > > > > As always, milestone builds like this are use-at-your-own-risk. There > are > > > > known bugs, and it definitely isn't ready for production use. Please > expect > > > > some trial and error getting everything to work. The javadoc that > comes > > > > bundled with the distribution should be up-to-date, but the online > Developer > > > > Guide ( > http://code.google.com/docreader/#p=google-web-toolkit-doc-1-6) is > > > > still very much a work in progress. We will be updating it over the > next > > > > several weeks. In lieu of an up-to-date Developer Guide and release > notes, > > > > below are the major highlights relative to GWT 1.5.3. > > > > > > *** New Project Structure in GWT 1.6 *** > > > > > > One of the biggest changes to GWT 1.6 is a new project structure. The > old > > > > output format has been replaced by the standard Java web app expanded > "war" > > > > format, and the actual directory name does default to "/war". Note > that the > > > > war directory is not only for compiler output; it is also intended to > > > > contain handwritten static resources that you want to be included in > your > > > > webapp alongside GWT modules (that is, things you'd want to version > > > > control). Please also note that the "GWTShell" and "GWTCompiler" > tools will > > > > maintain their legacy behavior, but they have been deprecated in > favor of > > > > new "HostedMode" and "Compiler" tools which use the new war output. > When 1.6 > > > > is officially released, we will be encouraging existing projects to > update > > > > to the new directory format and to use the new tools to take > advantage of > > > > new features and for compatibility with future GWT releases. > > > > > > The sample projects provided in the GWT distribution provide an > example of > > > > correct new project configurations. For more details on the specifics > of the > > > > new project format, please see GWT 1.6 WAR design document ( > http://code.google.com/p/google-web-toolkit/wiki/WAR_Design_1_6). > > > > > > A couple of important changes we should highlight here: > > > > > > - Projects with server-side code (GWT RPC) must configure a "web.xml" > file > > > > at "/war/WEB-INF/web.xml". This web.xml file must define and publish > any > > > > servlets associated with the web application. See the included > DynaTable > > > > sample. Additionally, server-side library dependencies must be copied > into > > > > "/war/WEB-INF/lib". For example, any GWT RPC servlets must have a > copy of > > > > gwt-servlet.jar in this folder. > > > > > > - HTML host pages will no longer typically be located in a GWT > module's > > > > public path. Instead, we'll be recommending that people take > advantage of > > > > the natural web app behavior for serving static files by placing host > pages > > > > anywhere in the war structure that makes sense. For exmaple, you > might want > > > > to load a GWT module from a JSP page located in the root of your web > app. To > > > > keep such handwritten static files separate from those produced by > the GWT > > > > compiler, the latter will be placed into module-specific > subdirectories. Any > > > > page that wishes to include a GWT module can do so via a script tag > by > > > > referencing the GWT-produced "<module>.nocache.js script" within that > > > > module's subdirectory. As of 1.6, we'll be recommending that only > > > > module-specific resources used directly by GWT code, such as image > files > > > > needed by widgets, should remain on the public path. See the included > > > > Showcase sample for some examples of this distinction. > > > > > > - When you do need to load resources from a module's public path, > always > > > > construct an absolute URL by prepending GWT.getModuleBaseURL(). For > example, > > > > 'GWT.getModuleBaseURL() + "dir/file.ext"'. This advice has not > changed, but > > > > in the past it was easy to be sloppy with this, because the host page > and > > > > GWT module typically lived in the same directory, so using a relative > URL > > > > would usually do the right thing. Now that GWT modules live in a > > > > subdirectory, you must reference public resources through > > > > GWT.getModuleBaseURL(). > > > > > > *** Hosted Mode Enhancements *** > > > > > > Although the legacy GWTShell still uses an embedded Tomcat server, > the new > > > > HostedMode runs Jetty instead. There is also a new "Restart Server" > button > > > > on the main hosted mode window. Clicking this button restarts the > internal > > > > Jetty server, which allows Java code changes to take effect on the > server > > > > without having to completely exit and restart hosted mode. This is > useful > > > > when making code changes to RPC servlets, or when serializable RPC > types are > > > > modified and the server and client are out of sync. > > > > > > *** New EventHandler System *** > > > > > > Event handlers have been added to replace the old event listeners > used by > > > > Widgets, History, and various other classes. The new system has a few > > > > differences from the old system: > > > > > > - EventHandler methods always take a single parameter: the GwtEvent > that the > > > > Widget fired. For example, ClickHandler has a single method > > > > onClick(ClickEvent). > > > > > > - Each GwtEvent contains accessors relevant to the event, such as the > key > > > > that was pressed on KeyEvents. Native events provide access to the > > > > underlying native event object. > > > > > > - Each EventHandler defines only one method, so you do not need to > create > > > > empty methods just to satisfy the interface requirements. > > > > > > For users who create their own Widgets, you no longer need to manage > > > > listeners manually. Every Widget has a HandlerManager that manages > all of > > > > its handlers. For native events, such as ClickEvent, just call > > > > addDomHandler() from within your code to register a handler and sink > the > > > > associated event on the Widget. When the native event is detected, > the > > > > handler will automatically be called. For logical events, such as > > > > SelectionEvent, call addHandler() and fire the event manually using > the > > > > fireEvent() method. > > > > > > You can see examples of EventHandler usage in many of the updated GWT > > > > widgets and samples, or in new projects created with the new > webAppCreator > > > > tool. > > > > > > You can now trigger a native event on almost any Element. Create a > new > > > > native event using the Document.create*Event() methods, then dispatch > it on > > > > a specific Element by calling Element.dispatchEvent(). These methods > allow > > > > you to expand your test coverage in ways that were previously > impossible. > > > > > > *** New Widgets *** > > > > > > DatePicker > > > > > > The new DatePicker and DateBox widgets allow your users to select a > date > > > > from a calendar. The Showcase sample provides examples of both of > these > > > > widgets. > > > > > > LazyPanel > > > > > > The new LazyPanel widget allows you to delay the creation of certain > > > > sections of your application until they are first accessed, improving > > > > startup performance. For example, if your application has a seldom > used > > > > "Help" section, you can wrap it in a LazyPanel and create the user > interface > > > > only if and when the user tries to access it. To use the LazyPanel, > extend > > > > the class and override the abstract createWidget() method. The > > > > createWidget() method will be called the first time you call > setVisible() on > > > > the LazyPanel. > > > > > > *** Fixed Issues *** > > > > > > Please see our bug tracker for a full list of fixed issues and > enhancements > > > > ( > http://code.google.com/p/google-web-toolkit/issues/list?can=1&q=statu... > > > > ). > > > > > > As always, please report bugs to our issue tracker ( > http://code.google.com/p/google-web-toolkit/issues/list) after doing a > quick > > > > search to see if your issue has already been reported. If you run > into a > > > > serious issue, feel free to also reply back to this thread. > > > > > > Happy coding, > > > > Scott, on behalf of the GWT team > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
