Re: GWT Polymer

[harshyadav]

Thanks a lot Manuel.

We use gwt polymer elements heavily and look forward for its future 
development.
I would be happy to contribute in the best of my abilities: mainly testing 
and reporting.

Regards,
Harsh Yadav

On Friday, April 21, 2017 at 3:10:06 PM UTC-4, Manuel Carrasco wrote:
>
> Hi all,
>
> From today, Vaadin has transferred the ownership of the 
> gwt-polymer-elements and gwt-api-generator libraries to me.
>
> https://github.com/manolo/gwt-polymer-elements/
> https://github.com/manolo/gwt-api-generator/
>
> Vaadin decision is based on encouraging communities to maintain polymer 
> bridges for their favourites frameworks, hence Vaadin can focus their 
> efforts on delivering high quality UI elements made in Polymer. It also 
> happened recently with the Angular2Polymer bridge.
>
> I will design a roadmap for the next months.
>
> I'm looking for contributors so let me know who is interested on any 
> matter: coding, testing, reporting, answering, etc, and I will grant access 
> to the repos.
>
> Thanks
> - Manolo
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

GWT Polymer

[Manuel Carrasco Moñino]

Hi all,

>From today, Vaadin has transferred the ownership of the
gwt-polymer-elements and gwt-api-generator libraries to me.

https://github.com/manolo/gwt-polymer-elements/
https://github.com/manolo/gwt-api-generator/

Vaadin decision is based on encouraging communities to maintain polymer
bridges for their favourites frameworks, hence Vaadin can focus their
efforts on delivering high quality UI elements made in Polymer. It also
happened recently with the Angular2Polymer bridge.

I will design a roadmap for the next months.

I'm looking for contributors so let me know who is interested on any
matter: coding, testing, reporting, answering, etc, and I will grant access
to the repos.

Thanks
- Manolo

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT/Maven development cycle takes much too long

[Juan Pablo Gardella]

I suggest to make a POC using
https://github.com/tbroyer/gwt-maven-archetypes/ archetype, using
modular-webapp.

On Fri, 21 Apr 2017 at 14:38 Magnus  wrote:

>
>>> So, "mvn package" should Just Work™ (package the lib, then package the
>> app using the lib's jar).
>>
>
> Yes, works!
>
>
>> "mvn gwt:devmode" and "mvn gwt:codeserver" should work without too much
>> configuration (configure warDir/launcherDir, possibly projects/modules)
>>
>
> Actually, it gives an error (see below):
>
> Could not find goal 'devmode' in plugin
> org.codehaus.mojo:gwt-maven-plugin:2.8.0 among available goals...
>
>
> I believe I have to extend the minimal top-level pom.xml, but how?
> And I'd like to leave the pom.xml in the sub folders as is, because they
> are working for their own... Is this possible?
>
>
>> This is also the point with the development cycle: When debugging,
>>> eclipse doesn't "see" the changed library source code, because it fetches
>>> the library source code from the jar file in its own target folder.
>>>
>>
>> Actually the one from your local repository (~/.m2/repository/), not
>> directly the one from the target/ folder.
>>
>
> This is an important point! If the app used the library jar from the
> repository and not from its own target directory, there would be no need to
> "mvn package" the app and this takes most of the time...
>
>
>> Wouldn't it be better for developing if the original library code was
>>> used instead? Could it be that this is the core of the problem?
>>>
>>
>>
>
>> And the problem is that Eclipse errors when importing your app project
>> when using the default configuration for resolving dependencies from the
>> workspace; which is why you turned that setting off.
>>
> If you figure out how to get this working, then it should (hopefully work)
>> the same with or without a reactor.
>>
>
> I can enable it for the lib project without problems. But as soon as I
> enable it for the app project, the error reappears.
> It's hard to figure it out when even the experts in this group have no
> idea. But I see that this is an essential point, so I have documented the
> error as detailed as possible again (see below). I hope there will be a
> solution...
>
> Thanks
> Magnus
>
>
>
> *Maven error when executing "mvn gwt:devmode" at the top-level:*
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] msm-lib-acs
> [INFO] msm.app.bcs.Application
> [INFO] msm
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] msm-lib-acs ... SKIPPED
> [INFO] msm.app.bcs.Application ... SKIPPED
> [INFO] msm ... SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 2.603s
> [INFO] Finished at: Fri Apr 21 19:13:32 CEST 2017
> [INFO] Final Memory: 10M/241M
> [INFO]
> 
> [ERROR] Could not find goal 'devmode' in plugin
> org.codehaus.mojo:gwt-maven-plugin:2.8.0 among available goals clean,
> compile, compile-report, css, debug, eclipse, eclipseTest, generateAsync,
> help, i18n, mergewebxml, resources, run, run-codeserver, source-jar, test
> -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoNotFoundException
>
>
>
>
>
> *Error in the application project's pom.xml when "resolve dependencies" is
> enabled:*
>
> The pom.xml has an error marker at the packaging tag:
>
>
> 
>
> The error behind this error marker is this:
>
> Failed to copy file for artifact
> [msm.lib.acs:msm-lib-acs:jar:1.0-SNAPSHOT:compile]
> (org.apache.maven.plugins:maven-war-plugin:2.2:war:default-war:package)
>
> org.apache.maven.plugin.MojoExecutionException: Failed to copy file for
> artifact [msm.lib.acs:msm-lib-acs:jar:1.0-SNAPSHOT:compile]
> at
> org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:131)
> at
> org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:190)
> at
> org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:109)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:472)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:404)

Re: GWT/Maven development cycle takes much too long

[Magnus]

>
>
>> So, "mvn package" should Just Work™ (package the lib, then package the 
> app using the lib's jar).
>

Yes, works!
 

> "mvn gwt:devmode" and "mvn gwt:codeserver" should work without too much 
> configuration (configure warDir/launcherDir, possibly projects/modules)
>

Actually, it gives an error (see below):

Could not find goal 'devmode' in plugin 
org.codehaus.mojo:gwt-maven-plugin:2.8.0 among available goals...


I believe I have to extend the minimal top-level pom.xml, but how?
And I'd like to leave the pom.xml in the sub folders as is, because they 
are working for their own... Is this possible?
 

> This is also the point with the development cycle: When debugging, eclipse 
>> doesn't "see" the changed library source code, because it fetches the 
>> library source code from the jar file in its own target folder.
>>
>
> Actually the one from your local repository (~/.m2/repository/), not 
> directly the one from the target/ folder.
>

This is an important point! If the app used the library jar from the 
repository and not from its own target directory, there would be no need to 
"mvn package" the app and this takes most of the time...
 

> Wouldn't it be better for developing if the original library code was used 
>> instead? Could it be that this is the core of the problem?
>>
>
>  

> And the problem is that Eclipse errors when importing your app project 
> when using the default configuration for resolving dependencies from the 
> workspace; which is why you turned that setting off.
> If you figure out how to get this working, then it should (hopefully work) 
> the same with or without a reactor.
>

I can enable it for the lib project without problems. But as soon as I 
enable it for the app project, the error reappears.
It's hard to figure it out when even the experts in this group have no 
idea. But I see that this is an essential point, so I have documented the 
error as detailed as possible again (see below). I hope there will be a 
solution...
 
Thanks
Magnus 



*Maven error when executing "mvn gwt:devmode" at the top-level:*

[INFO] Reactor Build Order:
[INFO] 
[INFO] msm-lib-acs
[INFO] msm.app.bcs.Application
[INFO] msm
[INFO] 

[INFO] Reactor Summary:
[INFO] 
[INFO] msm-lib-acs ... SKIPPED
[INFO] msm.app.bcs.Application ... SKIPPED
[INFO] msm ... SKIPPED
[INFO] 

[INFO] BUILD FAILURE
[INFO] 

[INFO] Total time: 2.603s
[INFO] Finished at: Fri Apr 21 19:13:32 CEST 2017
[INFO] Final Memory: 10M/241M
[INFO] 

[ERROR] Could not find goal 'devmode' in plugin 
org.codehaus.mojo:gwt-maven-plugin:2.8.0 among available goals clean, 
compile, compile-report, css, debug, eclipse, eclipseTest, generateAsync, 
help, i18n, mergewebxml, resources, run, run-codeserver, source-jar, test 
-> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, 
please read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoNotFoundException


 


*Error in the application project's pom.xml when "resolve dependencies" is 
enabled:*

The pom.xml has an error marker at the packaging tag:



The error behind this error marker is this:

Failed to copy file for artifact 
[msm.lib.acs:msm-lib-acs:jar:1.0-SNAPSHOT:compile] 
(org.apache.maven.plugins:maven-war-plugin:2.2:war:default-war:package)

org.apache.maven.plugin.MojoExecutionException: Failed to copy file for 
artifact [msm.lib.acs:msm-lib-acs:jar:1.0-SNAPSHOT:compile]
at 
org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:131)
at 
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:190)
at 
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:109)
at 
org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:472)
at 
org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:404)
at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:215)
at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:177)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at 
org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331)
at 

Re: GWT/Maven development cycle takes much too long

[Thomas Broyer]

On Friday, April 21, 2017 at 5:58:58 PM UTC+2, Magnus wrote:
>
> Hi Thomas,
>
> I already have started to play with a reactor. Below is my top-level 
> pom.xml. But where to go from here?
> What are the mvn commands to build everything on the top-level? If "mvn 
> install" isn't needed anymore, how does the app project see the library?
>

Because msm-apl-mcs has a dependency on msm-lib-acs, Maven will always 
build the latter before the former (when executed on the whole reactor).
If the "package" phase is part of the build (e.g. you execute "mvn package" 
or "mvn verify" for example), then the JAR for msm-lib-acs will be 
"attached" to the project and will be used by "msm-apl-mcs". Otherwise 
(e.g. you use "mvn test" or "mvn gwt:devmode"), "msm-lib-acs" will have no 
known attached artifact, so "msm-apl-mcs" will have to use something else 
(this is why I recommend never using phases before "package" when invoking 
Maven in reactors; the "gwt:devmode" goal has special handling for reactor 
builds, contrary to the "gwt:run" from the MojoHaus' plugin); and if 
msm-lib-acs has packaging 'jar' and the dependency is on the jar type with 
no classifier, then it'll be its target/classes folder, and otherwise it'll 
be nothing (IIRC).

So, "mvn package" should Just Work™ (package the lib, then package the app 
using the lib's jar).
"mvn gwt:devmode" and "mvn gwt:codeserver" should work without too much 
configuration (configure warDir/launcherDir, possibly projects/modules)
 

> This is also the point with the development cycle: When debugging, eclipse 
> doesn't "see" the changed library source code, because it fetches the 
> library source code from the jar file in its own target folder.
>

Actually the one from your local repository (~/.m2/repository/), not 
directly the one from the target/ folder.
 

> And this jar file is updated only by "mvn install" at the app project. 
> Wouldn't it be better for developing if the original library code was used 
> instead? Could it be that this is the core of the problem?
>

Yes, it is.
And the problem is that Eclipse errors when importing your app project when 
using the default configuration for resolving dependencies from the 
workspace; which is why you turned that setting off.
If you figure out how to get this working, then it should (hopefully work) 
the same with or without a reactor.
But with a reactor at least you can have things working with "mvn 
gwt:devmode" and/or "mvn gwt:codeserver" (and your developers could then 
possibly switch to other IDEs if you allow them to: NetBeans, IntelliJ 
IDEA, or even VSCode)
Tweaking the classpath for the DevMode launcher in Eclipse to include the 
lib's project and source folders could also be a temporary workaround while 
you figure things out on the Eclipse project import front.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT/Maven development cycle takes much too long

[Magnus]

Hi Thomas,

I already have started to play with a reactor. Below is my top-level 
pom.xml. But where to go from here?
What are the mvn commands to build everything on the top-level? If "mvn 
install" isn't needed anymore, how does the app project see the library?

This is also the point with the development cycle: When debugging, eclipse 
doesn't "see" the changed library source code, because it fetches the 
library source code from the jar file in its own target folder. And this 
jar file is updated only by "mvn install" at the app project. Wouldn't it 
be better for developing if the original library code was used instead? 
Could it be that this is the core of the problem?

Thanks
Magnus





-

pom.xml:
http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd;>

 4.0.0

 msm
 msm
 1.0
 pom

  pom

  
   msm-lib-acs
   msm-apl-mcs
  




-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Trying to run Super Dev Mode, but getting "Sorry, the GWT Developer Plugin no longer works with Chrome"

[Brandon Donnelson]

I notice you're using the older GPE plugin, I'll suggest jumping to the new 
GWT Eclipse Plugin. It's wired up to handle the switches for super dev 
mode. 

On Thursday, April 20, 2017 at 1:45:06 AM UTC-7, gitzzz87 wrote:
>
> Check the flag
>
>
>
> четверг, 20 апреля 2017 г., 6:07:41 UTC+7 пользователь Tharpa Roberts 
> написал:
>>
>> I am maintaining a legacy application, which uses GWT 2.6.1.  I am trying 
>> to run it in Eclipse.  I have added the line 
>>
>> 
>>
>> to my Acme.gwt.xml file.   I am selecting, "Debug As GWT Development Mode 
>> with Jetty".  When I open it, Chrome tells me, "Sorry, the GWT Developer 
>> Plugin no longer works with Chrome".  
>>
>> I want to use Super Dev Mode.  Why does it think that I want to use 
>> DevMode ?
>>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT Editor with Custom Composites

[Thomas Broyer]

On Wednesday, April 19, 2017 at 8:19:52 PM UTC+2, harshyadav wrote:
>
> Hi,
>
> I am trying to use the GWT editor framework to support data binding in my 
> application. While implementing it I ran into a few issues and have a 
> couple of questions regarding the same:
>
> 1) Some of these components don't use 
> com.google.gwt.user.*
>
>   rather they use 
> com.google.gwt.dom.client.*
>
>  For e.g. InputElement as opposed to TextBox. Is it possible to use editor 
> framework with dom elements?
>

Yes.
There are several ways.
Either your "composite editor" implements ValueAwareEditor; in setValue 
extracts values from object properties and put them into the elements, on 
flush() do the reverse.
@Override public void setValue(MyObj value) {
  this.value = value;
  myInputElement.setValue(value.getProp());
}
@Override public void flush() {
  this.value.setProp(myInputElement.getValue());
}
Or use "child" editors for each element, implement a LeafValueEditor that 
delegates to the element in setValue/getValue.
final LeafValueEditor myInputElementEditor = new 
LeafValueEditor() {
  @Override public String getValue() { return myInputElement.getValue(); }
  @Override public void setValue(String value) { 
myInputElement.setValue(value); }
};

2) Is it possible to bind POJO's with different field types (int, float, 
> String, etc.) to a single Composite implementing IsEditor?
> For e.g. if there is an Input composite (wrapping TextBox), is it possible 
> to use the same composite for POJO fields of different types int, float, 
> etc. ?
>
> public class Test
>  implements Serializable {
>
>  private Integer id;
>
>  private String name;
>
>  private float area;
> }
>
>
> Here name and area are of different type. Is it possible to bind these to 
> the same widget implementing Editor (without editor I would just parse the 
> values to and from String to their respective types before saving the data)?
>

The editor would have to have a generic type parameter (class MyEditor 
implements LeafValueEditor) and a way to convert the value it receives 
to/from String (e.g. passing converters to the constructor?)
Have a look at how ValueBox works.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Replacing StorageImpl with itself?

[Thomas Broyer]

This rule overrides the "built-in" one that replaces StorageImpl with 
StorageImplNonNativeEvents. It wouldn't be needed if that other rule hadn't 
existed.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Replacing StorageImpl with itself?

[Edward Scott]

hello - 

I am looking for some insight into what might be going on with the 
workaround to Wrong LocalStorage event fire #9205 
, an issue raised about a 
year and a half ago.

I have observed the behavior described in the issue. I have also followed 
the workaround described in the comments and found that it does work around 
the issue.

The workaround is to add the following configuration, which appears to 
replace StorageImpl with itself:

  


  
  
  
  

  


I am trying to understand - why does this change anything?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.