Custom Post Linker and Super Dev Mode

[MCMicS]

Hi,
I have written an own linker to generate file.
If I compile the App it works and the legacy DevMode works also fine.

But If I use SuperDevMode the file is not generated.

The reason ist that the SuperDevListener has following method:

  @Override
  public void writeCompilerOutput(StandardLinkerContext linkerStack, ArtifactSet artifacts,
      ModuleDef module, boolean isRelink) throws UnableToCompleteException {
    // The code server will do this.
  }

The linker is called but no artifact will be written.

How can I reach to generate a file (index.html, readme, ...) during compile step

Regards
Michael

[Geoffrey Wiseman]

I know this is a while back -- did you ever make any headway on this? I've seen this on a project and it wasn't a pressing concern, but if anyone has a fix for this, I'd be happy to hear it.

[Thomas Broyer]

IIRC, with Super Dev Mode, public artifacts aren't generated in the launcher dir; you need to build your path relative to GWT.getModuleBaseForStaticFiles() rather than GWT.getModuleBase(). HTH

[Geoffrey Wiseman]

On Wednesday, January 15, 2020 at 3:49:34 AM UTC-5, Thomas Broyer wrote:

IIRC, with Super Dev Mode, public artifacts aren't generated in the launcher dir; you need to build your path relative to GWT.getModuleBaseForStaticFiles() rather than GWT.getModuleBase(). HTH

Cautionary preamble: I wasn't involved in the creation of this linker, and I haven't done much with GWT linkers, so it is entirely possible that I'm missing something here. Having said all that:

The linker that I've seen break down in SuperDevMode just calls `emitString` to create some text resources that are then requested later by the browser. Those resources were visible to dev mode in the past, and they're visible in the built GWT application, but in SuperDevMode, they 404. Near as I can tell, the linker isn't using `getModuleBase` or `getModuleBaseForStaticFiles` at all.

But with this response I was able to find another thread:

https://www.mail-archive.com/google-we...@googlegroups.com/msg105012.html

Sounds like you were saying there that it may not be possible to fix this for SuperDevMode? It definitely *does* work in the final built WAR file, it's only SuperDevMode where this seems to break down. So if I create artifacts using `emitString` in a custom linker, there's no way to have these be accessible in SuperDevMode?

[Thomas Broyer]

On Monday, January 27, 2020 at 10:39:01 PM UTC+1, Geoffrey Wiseman wrote:

On Wednesday, January 15, 2020 at 3:49:34 AM UTC-5, Thomas Broyer wrote:

IIRC, with Super Dev Mode, public artifacts aren't generated in the launcher dir; you need to build your path relative to GWT.getModuleBaseForStaticFiles() rather than GWT.getModuleBase(). HTH

Cautionary preamble: I wasn't involved in the creation of this linker, and I haven't done much with GWT linkers, so it is entirely possible that I'm missing something here. Having said all that:

The linker that I've seen break down in SuperDevMode just calls `emitString` to create some text resources that are then requested later by the browser. Those resources were visible to dev mode in the past, and they're visible in the built GWT application, but in SuperDevMode, they 404. Near as I can tell, the linker isn't using `getModuleBase` or `getModuleBaseForStaticFiles` at all.

Those methods are to be called from the client code, not the linker itself.

 

But with this response I was able to find another thread:

https://www.mail-archive.com/google-web-toolkit@googlegroups.com/msg105012.html

Sounds like you were saying there that it may not be possible to fix this for SuperDevMode? It definitely *does* work in the final built WAR file, it's only SuperDevMode where this seems to break down. So if I create artifacts using `emitString` in a custom linker, there's no way to have these be accessible in SuperDevMode?

If you emitString() with a partialPath of "foo.txt", then it should be accessible in SDM at GWT.getModuleBaseForStaticFiles() + "foo.txt" (but not GWT.getModuleBaseURL() + "foo.txt"). In production mode, it'll be accessible through both, as getModuleBaseForStaticFiles and getModuleBaseURL return the same value then.

 

[Geoffrey Wiseman]

On Tuesday, January 28, 2020 at 4:48:32 AM UTC-5, Thomas Broyer wrote:

Those methods are to be called from the client code, not the linker itself.

Ok -- makes sense. If I modify the client code that makes those requests to use getModuleBaseForStaticFiles(), it looks like it's now trying to load them from the code server port instead -- assume that's expected?  If I log the output of both methods, I can see the ports are different.

Unfortunately, the new base URL doesn't seem to have helped me. Now I see "[WARN] ignored get request: /path/to/file" for the URL and if I make a curl request, I can see that it's coming back with a 200 and content length 0.

So .... it's different, but not totally working either?