css interface generation mvn goal missing? about gwt-maven-plugin HOT 7 CLOSED

It's intentionally not there, at least for the time being. The tools provided by GWT (CSS or I18N) are supposed to be one-off tools to help you bootstrap a project from existing files. At least that's how I see them; YMMV. So I don't plan to add those goals to the plugin, unless there's a huge demand for them (but you can use the exec-maven-plugin in the mean time)

from gwt-maven-plugin.

thanks for the fast answer Thomas!
Sadly I'm having difficulties to understand what you're saying. So I'll try to repeat what I understood:
CSS or I18N generations are supplied by GWT and you do not want to provide a wrapper for them in the newer version of you're gwt-maven-plugin, because you say that they are only helpful for migrating existing projects, not for new ones?

But there exists some other maven plugin called exec-maven-plugin that allows to use them without you wrapping them? Could you give details how that would work?

from gwt-maven-plugin.

That's it. The CodeHaus Mojo binds them to build phases by default, and I believe this is a mistake.

As for the exec-maven-plugin, apparently it's not powerful enough (InterfaceGenerator outputs the class to standard output, and exec-maven-plugin provides no way to redirect that output to a file); but the antrun-maven-plugin should work.

<plugin>
  <artifactId>maven-antrun-plugin</artifactId>
  <version>1.8</version>
  <configuration>
    <sourceRoot>${project.build.directory}/generated-sources/css</sourceRoot>
    <target>
      <java fork="true" failonerror="true"
        classname="com.google.gwt.resources.css.InterfaceGenerator"
        output="${maven.project.build.directory}/generated-sources/css/net/example/client/Whatever.java" logError="true">
        <classpath>
          <pathentry location="${com.google.gwt:gwt-dev:jar}"/>
          <pathentry location="${com.google.gwt:gwt-user:jar}"/>
        </classpath>
        <arg>-addPackageHeader</arg>
        <arg>-typeName</arg>
        <arg>net.example.client.Whatever</arg>
        <arg>-css</argument>
        <arg>src/main/resources/net/example/client/whatever.css</arg>
      </java>
    </target>
  </configuration>

from gwt-maven-plugin.

Thanks for the maven-antrun-plugin pom.xml snippet! - I'll try that soon.

In the meantime I've generated myself a project from tbroyer/gwt-maven-archetypes@3f53aa7 but it sadly requires the use of the SuperDevMode booklets, a project generated from trunk containing your new gwt-maven-plugin does trigger the compiling automatically by simply refreshing the page. thats much nicer.

About the binding the codeGeneration execution to a phase in maven - what alternatives are there? If you don't bind the execution to a phase, it won't get executed during build, or will it?

from gwt-maven-plugin.

In the meantime I've generated myself a project from tbroyer/gwt-maven-archetypes@3f53aa7 but it sadly requires the use of the SuperDevMode booklets, a project generated from trunk containing your new gwt-maven-plugin does trigger the compiling automatically by simply refreshing the page. thats much nicer.

Add a <launcherDir> (or pass -Dgwt.codeServer.launcherDir=… on the command-line) to the gwt-maven-plugin in the *-client project pointing to ${project.build.directory}/${project.build.finalName}, or just use gwt:run instead of gwt:run-codeserver.

About the binding the codeGeneration execution to a phase in maven - what alternatives are there? If you don't bind the execution to a phase, it won't get executed during build, or will it?

Run it once and commit the generated file. Maybe it's not the case for CSS (and I haven't evaluated GSS yet), but for I18N the generated file can only be a starting point: you'll change return types in Constants and parameter types in Messages to things other than String, you'll possibly change return types in Messages to SafeHtml, you'll add @AlternateMessage and @Select, etc.

from gwt-maven-plugin.

thanks for that hint with the <launcherDir> tag, that works nicely!

One other problem I have observed: most of the time when I try to kill the codeserver by pressing the red stop button in eclipse it won't die and I have to kill it in htop (or the like) before a new one will successfully start (address in use error). Do you know what might cause this or how to prevent that?

About the code generation: I've never wanted to manually modify a I18N generated file (I've only used Strings as of yet..), neither CSS or RPC-Async interface - but I do by time edit the messages text files, the css files or add new methods to my RPC interface - And I very much prefer for the generated code to get updated automatically during build time. But that's a matter of developers preference I guess.

from gwt-maven-plugin.

One other problem I have observed: most of the time when I try to kill the codeserver by pressing the red stop button in eclipse it won't die and I have to kill it in htop (or the like) before a new one will successfully start (address in use error). Do you know what might cause this or how to prevent that?

That's an Eclipse issue. Eclipse force-kills processes, it doesn't ask them to gracefully shutdown, so among other things shutdown hooks aren't invoked (GWT leaves a whole lot of temp files in your temp dir) and forked processes aren't killed.

About the code generation: I've never wanted to manually modify a I18N generated file (I've only used Strings as of yet..), neither CSS or RPC-Async interface - but I do by time edit the messages text files, the css files or add new methods to my RPC interface - And I very much prefer for the generated code to get updated automatically during build time. But that's a matter of developers preference I guess.

I suppose. Note that you can continue to use those goals from the org.codehaus.mojo:gwt-maven-plugin, without using the compile goal, if they fit your needs (well, yes, no need for the maven-antrun-plugin after all… I suppose I need some sleep or coffee).

from gwt-maven-plugin.