Thursday, September 17, 2015

Re: JsInterop hello world

I use gwt-maven-plugin 2.8.0-SNAPSHOT for no reason in particular, 
but if you use 2.7.0 and you want to compile correctly with version 2.8.0 of GWT, remember to override the plugin configuration like explained in this page https://gwt-maven-plugin.github.io/gwt-maven-plugin/user-guide/using-different-gwt-sdk-version.html

<plugin>
 
<groupId>org.codehaus.mojo</groupId>
 
<artifactId>gwt-maven-plugin</artifactId>
 
<version>2.7.0</version>
 
<dependencies>
   
<dependency>
     
<groupId>com.google.gwt</groupId>
     
<artifactId>gwt-user</artifactId>
     
<version>2.8.0-SNAPSHOT</version>
   
</dependency>
   
<dependency>
     
<groupId>com.google.gwt</groupId>
     
<artifactId>gwt-dev</artifactId>
     
<version>2.8.0-SNAPSHOT</version>
   
</dependency>
   
<dependency>
     
<groupId>com.google.gwt</groupId>
     
<artifactId>gwt-codeserver</artifactId>
     
<version>2.8.0-SNAPSHOT</version>
   
</dependency>
 
</dependencies>

</plugin>

In the fork of your project I used gwt-maven-plugin 2.8.0-SNAPSHOT only to avoid adding these explicit dependencies on the plugin (gwt-maven-plugin 2.7.0 compiles by default with GWT 2.7.0).


It is weird that you get dependencies resolved on nexus.codehaus.org - btw codehaus.org has closed so it make sense it does not work, it is weird that it uses it...
I don't know which of your dependencies does it trigger resource resolution in that repo.
Keep your git repo up-to-date in case so I can check it exactly if you need more help.

bye,

Cristiano


Il giorno giovedì 17 settembre 2015 15:07:20 UTC+2, Brian Pedersen ha scritto:
It all makes perfectly sense now, thank's a lot for taking your time to clarify your findings.

I like the concept of the sso linker, a pity it doesn't work with super dev mode yet. 
Using JsInterop with the xsiframe linker in super dev mode works equally bad for me, but maybe that's just me messing things up ;)

For some reason, I can't build your code with the 2.8.0-SNAPSHOT version of the gwt-maven-plugin.
I can check out and build the plugin sucessfully, but then when I build your projects, it apparently tries to resolve the gwt dependencies through the nexus.codehaus.org repository and fails.

But it all works perfectly when I build it with the 2.7.0 version of the gwt-maven-plugin, as long as I run it with jetty:run and not gwt:run.

What are your reasons for using the 2.8.0 version of the gwt-maven-plugin?

Thanks ...
/Brian


Den torsdag den 17. september 2015 kl. 10.02.13 UTC+2 skrev Cristiano:
Update:

with the sso linker the project responds as expected: the GWT code is available as soon as page has loaded

You could check it out on this branch:

note that: 
- with sso linker super dev mode don't work (I've worked manually compiling javascript and testing the compiled code directly)
- sso works only if you have exactly one permutation, and to obtain exactly 1 permutation I've removed inheritance of 'com.google.gwt.user.User' module (in fact your example was not using anything from that module)





Il giorno giovedì 17 settembre 2015 09:18:34 UTC+2, Cristiano ha scritto:
Hi Brian,

I had problems similar to you when studying JsInterop, so I've tried your code.
I've forked your repo (see https://github.com/cristcost/jspoc) and I have made it work but with some considerations to take into account.
Other than the problems on using JsInterop annotations as reported by Jens, I've found a script load timing issue:
you execute the the Javascript code in the main page script, but at that point GWT has not yet loaded!

Putting the execution of your javascript code inside window.onload event is not again enough: I think this is because of using the xsiframe linker (I'm curious to try out with the sso linker).
So I have used a 3 seconds timeout... 

In the fork I've added some console logging to outline the time each part of the Javascript is executed, and the order is:
- first javascript inside main html page is executed
- then javascript inside the window.onload
- finally the GWT entry point

Your javascript code, with the fixes suggested by Jens, has worked after a 3 seconds timeout.

Of course I don't like this workaround, but a more general approach could be to have your application started from the GWT entry point (i.e. define a "main" function in javascript, then run it from GWT entry point). If you don't like the ping-pong between JS and GWT, you may try different solution to detect when GWT has loaded, or - if the problem is the xsiframe linker - try another linker.


Please note that I've changed totally the pom.xml and copied configuration from one of mines: in particular I have added a configuration for maven-jetty-plugin, 
so to try it out you need can execute the following commands:

git clone https://github.com/cristcost/jspoc.git
cd jspoc
mvn clean install
mvn jetty
:run


After this you should be able to open your browser at http://localhost:8888/ and you should see the alert popup (but 3 seconds after the page load!)

Hope this is helpful,

Cristiano


PS. I'm using gwt 2.8.0-SNAPSHOT and also gwt-maven-plugin 2.8.0-SNAPSHOT that I have compiled personally, so I don't have added the repo on the pom.xml,
you should re-add it from your pom.xml or compile the two by yourself. The gwt-maven-plugin 2.8.0-SNAPSHOT is available at https://github.com/gwt-maven-plugin/gwt-maven-plugin and I compile it skipping the tests with

 mvn clean install -DskipTests







--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment