css interface generation mvn goal missing?

[kaefert]

the old maven plugin

<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>

does have a css-generation goal which allows to auto generate an interface for css files which makes it easier to use it from within gwt code. Is this simply not yet implemented in the new beta version, or has this been intentionally removed?

(my goal is to setup a gwt 2.7 project with gss style sheets that I want to use in UiBinder definitions and in gwt java code)

[tbroyer]

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)

[kaefert]

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?

[tbroyer]

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>

[kaefert]

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?

[tbroyer]

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.

[kaefert]

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.

[tbroyer]

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).