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
-~----------~----~----~----~------~----~------~--~---
