> Congratulation for this release. > > Unfortunately, there's still nothing about Maven support. No official > repository, no official plugin.... I hope this will arrive this > Milestone 2. > > Regards, > Alexandre de Pellegrin
I think you'll note that GWT is in the central Maven repository (http://repo1.maven.org/maven2/com/google/gwt/) and there are currently at least two Maven plugins (being merged), the gwt-maven plugin: http://code.google.com/p/gwt-maven/ and the Codehaus GWT plugin: http://mojo.codehaus.org/gwt-maven-plugin/. I and a number of other people use Maven every day, and it works OK. I'm sure it could be better, but it does work. -- Arthur Kalmenson On Wed, Feb 11, 2009 at 4:29 AM, Alex dP (Violet UML Editor, WebVNC...) <alexandre.de.pelleg...@gmail.com> wrote: > > Congratulation for this release. > > Unfortunately, there's still nothing about Maven support. No official > repository, no official plugin.... I hope this will arrive this > Milestone 2. > > Regards, > Alexandre de Pellegrin > > On Feb 6, 4:26 pm, Scott Blum <sco...@google.com> 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 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 -~----------~----~----~----~------~----~------~--~---
