2

As stated in the documentation of rest-dispatch, the rest application path must be configured in the GIN module via a constant, here "/api/v1":

public class DispatchModule extends AbstractGinModule {
   @Override
   protected void configure() {
       RestDispatchAsyncModule.Builder dispatchBuilder = 
               new RestDispatchAsyncModule.Builder();
       install(dispatchBuilder.build());
       bindConstant().annotatedWith(RestApplicationPath.class).to("/api/v1");   
   }
}

I would like to make the "/api/v1" constant be resolved at compile time, based on an environment variable set by the build system depending on the target environment (prod, dev, etc...), and on other criteria (the build artifact major version...).

The problem is I do not manage to rely on a compile time variable. Neither TextResource/CssResource nor GWT's deferred binding won't help here, since GWT.create() cannot be used in GIN module. Another option I considered is using a custom Generator, but this seems to be too complex for this very simple need.

How do you solve this problem ?

Eric Citaire
  • 4,355
  • 1
  • 29
  • 49

3 Answers3

4

If you use Maven as your build system, you could leverage the templating-maven-plugin to generate a Java class that will contain static variables defined in your POM file. That generated class will be used by your GWT code.

For example, you would want to populate a BuildConstants class template

public class BuildConstants {
  // will be replaced by Maven
  public static final String API_VERSION  = "${myapi.version}";
}

and using a Maven property:

<myapi.version>v1</myapi.version>

that will be compiled to

public class BuildConstants {
  // will be replaced by Maven
  public static final String API_VERSION  = "v1";
}

and you could reference those constants from within your DispatchModule:

bindConstant().annotatedWith(RestApplicationPath.class).to("/api/" + BuildConstants.API_VERSION);   

Here's a sample config of the templating-maven-plugin that I use in a project:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>templating-maven-plugin</artifactId>
  <version>1.0-alpha-3</version>
  <executions>
    <execution>
      <id>filter-src</id>
      <goals>
        <goal>filter-sources</goal>
      </goals>
      <configuration>
        <sourceDirectory>${basedir}/src/main/java-templates</sourceDirectory>
        <outputDirectory>${project.build.directory}/generated-sources/java-templates
        </outputDirectory>
      </configuration>
    </execution>
   </executions>
</plugin>
spg
  • 9,309
  • 4
  • 36
  • 41
1

There's no reason you couldn't replace the bindConstant() with a @Provides method (or other bind().toProvider(), which would let you use a TextResource and/or deferred-binding, or whatever.

Asn an example (untested though), the code below uses JSNI to read the value from the host page, which makes it runtime dependent (rather than compile-time):

@Provides @RestApplicationPath native String provideRestApplicationPath() /*-{
  return $wnd.restApplicationPath;
}-*/;
Thomas Broyer
  • 64,353
  • 7
  • 91
  • 164
0

Following Thomas Broyer suggestion and Simon-Pierre, you could even bind different root .gwt.xml files depending on your maven profile. Then you choose the appropriate Gin module class where your constants are bound.

That is what we do inside the CarStore companion project of GWTP do do Form factors for example.