Thursday, February 28, 2019

Possible validation bug

I created an issue in github for an possible validation related bug.


I'm trying to get hibernate-validator 6.0.X to work and have run into an issue and am not sure if what I'm seeing in the GWT codebase is a bug or not.

I'm using Validator.validateValue(...) in my tests and have encountered a bug where constraints on collections aren't being enforced. For example, I have:

public class Foo {
   
@NotEmpty List<String> strings;
}


 If 'strings' is set to Collections.emptyList() I should get a violation and I do when I call Validator.validate(obj) and Validator.validateProperty(obj, "strings") but not when I call Validator.validateValue(Foo.class, "strings", Collections.emptyList()).

The reason comes down to this snippet at line 2040 of com.google.gwt.validation.rebind.GwtSpecificValidatorCreator:

if (!isIterableOrMap(property.getElementClass())) {
    writeValidatePropertyCall(sw, property, true, false);
}

The call to writeValidatePropertyCall is only conditional in the Validator.validateValue(...) path.

There seem to be a lot of hidden gotchas with GWT so I'm wondering if there is a reason for the conditional to be there or if it's safe to remove it. I have removed it in my local code and my tests pass just fine but I'm concerned about unintended consequences.

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Wednesday, February 27, 2019

Converting an old applet to webapp: GWT is amazing!

Hello,

In 2003, I had a website with small games, GouziGouza, which relied heavily on applets. I lost the code when the server hosting the site crashed...Since that incident, the website was down. However, I recently found an old USB key at the bottom of a drawer. I plugged it in, and I found the source code of GouziGouza. Not the last version, but close enough.

As a side project, very quickly, I was able to convert the code from applets to GWT.

I do believe GWT has a bright future, especially when GWT 3.0 will be released!

You can try it at https://gouzigouza.com

Enjoy!

Best,
Paul

PS: I also made a short youtube video: https://www.youtube.com/watch?v=Uy_QgoqAsCU 

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Tuesday, February 26, 2019

Re: Tips on libraries

First of all thanks for the suggestions (Thomas, Pavlo, Frank). 

I understand your point of view Thomas, unfortunately I have some constraints, both in terms of budget and delivery times, which I must take into consideration; this is why I said that I must be productive and, for example, abandoning GIN for Dagger is not so simple: as you said, GWTP is a framework and I should try to replace all the different features I have available with something equivalent. However, I will take into consideration the various ideas that have been mentioned in previous posts, thanks again.

As for the part of pure graphical interface, has any of you ever tried to integrate a framework using JsInterop (eg Bootstrap 4)? Is it a viable way or am I saying nonsense? :-)

Il giorno lunedì 25 febbraio 2019 16:31:00 UTC+1, Thomas Broyer ha scritto:


On Monday, February 25, 2019 at 3:08:35 PM UTC+1, Ramon Flamia wrote:
Thanks Thomas, I imagined this answer :-) 

As I wrote in the initial post, my biggest concern is being updated with the UI, so I'm waiting for someone to show me his experience with other UI libraries, maybe even with JsInterop. I have seen the showcases of GWT Material and Domino UI, but I would like to understand how they fit together with the other technologies I have mentioned.

Your suggestions are very useful, but at the moment I do not think I can follow them. Let's me explain my point of view: one thing that struck me when reading the various blog or posts related to GWT is that there is this desire to create code that is already future-proof. But today the release of GWT 3.0 has not yet been announced, nor do we know good specifications. Correct me if I'm wrong: is the advice to avoid GWT generators just to be ready for the future? If so, I see it as a violation of YAGNI.

The main idea is to not lock yourself into choice that will be hard to replace. GWT Places are OK because the generator is optional, and so simple that it can easily be implemented as an annotation processor (and has already been rewritten this was). GIN would be OK too, but the replacement is Dagger 2, which is already available, heavily used (on Android, not necessarily GWT) and actively maintained; so why pick GIN now to later have to migrate to Dagger 2, rather than directly choose Dagger?
What I'm trying to say is to choose wisely: if there's a path forward, or it would relatively easily be replaced/abstracted, then use it; if it's highly structuring and is barely maintained, then carefully balance the gains vs costs/risks; and this of course depends on the expected lifetime of your project.
Beware that browsers' behaviors change, and that an unmaintained client library/framework might mean a broken app in the future; take that into account into your risk evaluation.
 
In particular, if I completely exclude the use of GWTP, I lose some things:
  • integration with a dependency injection framework (to this you already answered me, telling me to replace GIN with Dagger)
  • MVP architecture and consequently difficulty in carrying out TDD development
  • management of the browser history (probably in the link that you indicated to me, related to gwt-places, I can find something interesting)
  • years of experience with this library, which makes me very productive
From what I understand, GWTP is a framework, not a library. The cost of changing to anything else is high.
GWT Places and Activities worked well for me, and is lighter, less "framework-y"; MVP is easy to apply as a pattern, and doesn't necessitate a framework/library. See https://github.com/tbroyer/gwt-maven-archetypes/tree/master/dagger-guice-rf-activities/src/main/resources/archetype-resources/__rootArtifactId__-client/src/main/java for a dummy example.
 
Also, if I have to avoid GWT generators then it means that the GWT Editors and JSR-303 part (Validation) must also be replaced, right?

Bean Validation is already deprecated in GWT proper, so use it at your own risk (you may want to try https://gitlab.com/ManfredTremmel/gwt-bean-validators/tree/master/gwt-bean-validators though)
Editors have a migration path: https://github.com/DominoKit/gwt-editors (they might not play well with gwt-bean-validators though)

You can have a look at https://docs.google.com/spreadsheets/d/1b1D9fEqRh5lZ8cqMJtYoc_25rfTRvsuJkTtS2vjgi3o/edit?usp=sharing for a glance of what GWT 3 might look like.
 
Finally, I had already imagined replacing RPC calls with REST (RestyGwt maybe?), but I have to do some tests first to check that it is advantageous.

From my own tests, JsInterop work great for modelling JSON requests and responses (you can use com.google.gwt.http for requests, or directly XMLHttpRequest, from com.google.gwt.xhr or JsInterop/Elemental2, or fetch through JsInterop/Elemental2). Depending on your browser support needs, URLSearchParams could be used for application/x-www-form-urlencoded requests (https://caniuse.com/#feat=urlsearchparams), and you could always use polyfills for wider browser support.
 
So, if the answer at "Is there one or more framework that offers the same features as GWTP and whose learning curve is fast enough?" is "No", then I'll continue to use GWTP + GIN: I need to be as productive as I am now and I think that modularizing code and using best-practices in class design is the best way to get a feature-proof code (if and when GWT 3.0 is released then I'll see what do...). Otherwise, please tell me how I can replace all the features I've talked about.

Use what works best for you, but not (only) because you're already proficient with it, also weight in the costs/risks of later change (and yes, architecture plays a big role in the equation).

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Monday, February 25, 2019

[ANN] (Unofficial) Elemental2 1.0.0-b19-fb227e3 release

Elemental2 provides type checked access to browser APIs for Java
code. This is done by using closure extern files and generating
JsTypes, which are part of the new JsInterop specification that
is both implemented in GWT and J2CL.


This is an unofficial release to Maven Central under a different groupId.
Please don't bug the original authors. Versions are released on demand.

API Changes relative to Elemental2 version 1.0.0-b18-f3472e7

* All of the poms that are part of the release have been updated to reference
  a more recent version of the jsinterop-base dependency

elemental2-dom:
  11 non breaking changes.
* Added field elemental2.dom.CanvasRenderingContext2D.imageSmoothingEnabled
* Several improvements around fetch API

The Maven dependencies can be added to your pom.xml via

    <dependency>
      <groupId>org.realityforge.com.google.elemental2</groupId>
      <artifactId>${artifact-id}</artifactId>
      <version>1.0.0-b19-fb227e3</version>
    </dependency>

where artifact-id is one of

* elemental2-core
* elemental2-dom
* elemental2-promise
* elemental2-indexeddb
* elemental2-svg
* elemental2-webgl
* elemental2-media
* elemental2-webstorage
* elemental2-webassembly

Hope this helps,

Peter Donald

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Tips on libraries



On Monday, February 25, 2019 at 3:08:35 PM UTC+1, Ramon Flamia wrote:
Thanks Thomas, I imagined this answer :-) 

As I wrote in the initial post, my biggest concern is being updated with the UI, so I'm waiting for someone to show me his experience with other UI libraries, maybe even with JsInterop. I have seen the showcases of GWT Material and Domino UI, but I would like to understand how they fit together with the other technologies I have mentioned.

Your suggestions are very useful, but at the moment I do not think I can follow them. Let's me explain my point of view: one thing that struck me when reading the various blog or posts related to GWT is that there is this desire to create code that is already future-proof. But today the release of GWT 3.0 has not yet been announced, nor do we know good specifications. Correct me if I'm wrong: is the advice to avoid GWT generators just to be ready for the future? If so, I see it as a violation of YAGNI.

The main idea is to not lock yourself into choice that will be hard to replace. GWT Places are OK because the generator is optional, and so simple that it can easily be implemented as an annotation processor (and has already been rewritten this was). GIN would be OK too, but the replacement is Dagger 2, which is already available, heavily used (on Android, not necessarily GWT) and actively maintained; so why pick GIN now to later have to migrate to Dagger 2, rather than directly choose Dagger?
What I'm trying to say is to choose wisely: if there's a path forward, or it would relatively easily be replaced/abstracted, then use it; if it's highly structuring and is barely maintained, then carefully balance the gains vs costs/risks; and this of course depends on the expected lifetime of your project.
Beware that browsers' behaviors change, and that an unmaintained client library/framework might mean a broken app in the future; take that into account into your risk evaluation.
 
In particular, if I completely exclude the use of GWTP, I lose some things:
  • integration with a dependency injection framework (to this you already answered me, telling me to replace GIN with Dagger)
  • MVP architecture and consequently difficulty in carrying out TDD development
  • management of the browser history (probably in the link that you indicated to me, related to gwt-places, I can find something interesting)
  • years of experience with this library, which makes me very productive
From what I understand, GWTP is a framework, not a library. The cost of changing to anything else is high.
GWT Places and Activities worked well for me, and is lighter, less "framework-y"; MVP is easy to apply as a pattern, and doesn't necessitate a framework/library. See https://github.com/tbroyer/gwt-maven-archetypes/tree/master/dagger-guice-rf-activities/src/main/resources/archetype-resources/__rootArtifactId__-client/src/main/java for a dummy example.
 
Also, if I have to avoid GWT generators then it means that the GWT Editors and JSR-303 part (Validation) must also be replaced, right?

Bean Validation is already deprecated in GWT proper, so use it at your own risk (you may want to try https://gitlab.com/ManfredTremmel/gwt-bean-validators/tree/master/gwt-bean-validators though)
Editors have a migration path: https://github.com/DominoKit/gwt-editors (they might not play well with gwt-bean-validators though)

You can have a look at https://docs.google.com/spreadsheets/d/1b1D9fEqRh5lZ8cqMJtYoc_25rfTRvsuJkTtS2vjgi3o/edit?usp=sharing for a glance of what GWT 3 might look like.
 
Finally, I had already imagined replacing RPC calls with REST (RestyGwt maybe?), but I have to do some tests first to check that it is advantageous.

From my own tests, JsInterop work great for modelling JSON requests and responses (you can use com.google.gwt.http for requests, or directly XMLHttpRequest, from com.google.gwt.xhr or JsInterop/Elemental2, or fetch through JsInterop/Elemental2). Depending on your browser support needs, URLSearchParams could be used for application/x-www-form-urlencoded requests (https://caniuse.com/#feat=urlsearchparams), and you could always use polyfills for wider browser support.
 
So, if the answer at "Is there one or more framework that offers the same features as GWTP and whose learning curve is fast enough?" is "No", then I'll continue to use GWTP + GIN: I need to be as productive as I am now and I think that modularizing code and using best-practices in class design is the best way to get a feature-proof code (if and when GWT 3.0 is released then I'll see what do...). Otherwise, please tell me how I can replace all the features I've talked about.

Use what works best for you, but not (only) because you're already proficient with it, also weight in the costs/risks of later change (and yes, architecture plays a big role in the equation).

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Tips on libraries

I forgot to mention: There are project generators for mvp4g2: http://www.mvp4g.org/gwt-boot-starter-mvp4g2/GwtBootStarterMvp4g2.html and Nalu: https://github.com/nalukit/gwt-boot-starter-nalu. So, you can easily get an impression how they work.

Both frameworks work well with Domino-UI.

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Tips on libraries

I forgot to mention: There are project generators for mvp4g2: http://www.mvp4g.org/gwt-boot-starter-mvp4g2/GwtBootStarterMvp4g2.html and Nalu: https://github.com/nalukit/gwt-boot-starter-nalu.

Both frameworks work well with Domino-UI.

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Tips on libraries

Before I start, I would like to say, that I am a contributor of mvp4g and the owner of mvp4g2 and Nalu. All these libs could be a replacement for GWTP.

As Thomas already mentioned, I would avoid using libs based on GWT generators. So mvp4g will be no choice today. Mvp4g2 and Nalu both use annotation processors. Mvp4g2 has been successfully tested with J2CL and Nalu will also work with J2Cl cause it has no dependency to GWT. If you have already build something on mvp4g, I think mvp4g2 should be your choice. Otherwise I would give Nalu a try. Mvp4g2 and Nalu do not provide any widgets nor something for the communication with the server. 

To communicate with the server I prefer using REST.

In the past I like GXT very much. Currently, I am unsure about the future of GXT. My current choice would be Domino-UI, in case I am looking for a widget lib. Domino-UI is also ready to go with J2CL and the support of the Domino-UI team is awesome.

You will find more informations about mvp4g2 here: https://github.com/mvp4g/mvp4g2, about Nalu here: https://github.com/NaluKit/nalu and Domino-UI here: https://github.com/DominoKit/domino-ui.

May be also interesting: vue-gwt (https://github.com/VueGWT/vue-gwt) 

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Tips on libraries

Before I'll start, I would like to say, that I am a contributor of mvp4g and the owner of mvp4g2 and Nalu. All these libs could be a replacement for GWTP.

As Thomas already mentioned, I would avoid using libs based on GWT generators. So mvp4g will be no choice today. Mvp4g2 and Nalu both use anotation processors. Mvp4g2 has been successfully tested with J2CL and Nalu will also work with J2Cl cause it has no dependency to GWT. If you have already build something on mvp4g, I think mvp4g2 should be your chioce. Otherwise I would give Nalu a try. Mvp4g2 and Nalu do not provide any widgets nor somnething for the communication with the server. 

To cummincate with the server I prefer using REST.

In the past I like GXT very much. Currently, I am unsure about the future of GXT. My current choice would be Domino-UI, in case I am looking for a widget lib. Domino-UI is also ready to go with J2CL and the support of the Domino-UI team is awesome.

You will ifnd more inforamtions about mvp4g2 here: https://github.com/mvp4g/mvp4g2, about Nalu here: https://github.com/NaluKit/nalu and Domino-UI here: https://github.com/DominoKit/domino-ui.

May be also intresting: vue-gwt (https://github.com/VueGWT/vue-gwt) 

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Tips on libraries

Thanks Thomas, I imagined this answer :-) 

As I wrote in the initial post, my biggest concern is being updated with the UI, so I'm waiting for someone to show me his experience with other UI libraries, maybe even with JsInterop. I have seen the showcases of GWT Material and Domino UI, but I would like to understand how they fit together with the other technologies I have mentioned.

Your suggestions are very useful, but at the moment I do not think I can follow them. Let's me explain my point of view: one thing that struck me when reading the various blog or posts related to GWT is that there is this desire to create code that is already future-proof. But today the release of GWT 3.0 has not yet been announced, nor do we know good specifications. Correct me if I'm wrong: is the advice to avoid GWT generators just to be ready for the future? If so, I see it as a violation of YAGNI.

In particular, if I completely exclude the use of GWTP, I lose some things:
  • integration with a dependency injection framework (to this you already answered me, telling me to replace GIN with Dagger)
  • MVP architecture and consequently difficulty in carrying out TDD development
  • management of the browser history (probably in the link that you indicated to me, related to gwt-places, I can find something interesting)
  • years of experience with this library, which makes me very productive
Also, if I have to avoid GWT generators then it means that the GWT Editors and JSR-303 part (Validation) must also be replaced, right?
Finally, I had already imagined replacing RPC calls with REST (RestyGwt maybe?), but I have to do some tests first to check that it is advantageous.

So, if the answer at "Is there one or more framework that offers the same features as GWTP and whose learning curve is fast enough?" is "No", then I'll continue to use GWTP + GIN: I need to be as productive as I am now and I think that modularizing code and using best-practices in class design is the best way to get a feature-proof code (if and when GWT 3.0 is released then I'll see what do...). Otherwise, please tell me how I can replace all the features I've talked about.

Thanks again,
Ramon

Il giorno lunedì 25 febbraio 2019 12:59:15 UTC+1, Thomas Broyer ha scritto:

On Monday, February 25, 2019 at 12:33:23 PM UTC+1, Ramon Flamia wrote:
Hi everyone,
having to start a new GWT project, on average complex, which framework / technologies you recommend for the following points:

- MVP architecture (currently using GWTP)
- dependency injection (currently using GIN)
- communication with the server (currently using GWT RPC, provided by GWTP)
- UI (currently using GwtBootstrap3)

I ask this question because it seems to me that all the libraries I have mentioned do not foresee new developments; for the GIN and GWTP part this is not a problem, because these libraries are very stable; instead, the part of UI is the one that worries me the most, as there is no upgrade to version 4 of Bootstrap.

Can't give any recommendation wrt UI, as I never used any 3rd-party library and have only worked on maintaining legacy projects for the last years, or GWTP (always used plain old GWT Places and Activities), but GIN ⇒ Dagger 2 (and replace GIN Assisted Injection with either AutoFactory or AssistedInject), and I'd try to avoid GWT-RPC.
Try to avoid anything based on GWT generators these days, and this includes GWTP. People generally use a generator with GWT Places, but it can trivially be replaced with an annotation processor or hand-written code so it's future-proof (work is already done btw: https://github.com/gwtproject/gwt-places)

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Tips on libraries

Here is an answer about Nalu and GWTP from the main developer of both

https://groups.google.com/d/msg/Google-Web-Toolkit/FdSNvhrn3lE/ecwPrQ7dBAAJ

and dominoUI looks like a good set of components - https://dominokit.github.io/domino-ui-demo/index.html?theme=indigo#home
I personally use SmartGWT just because I need powerful table component and calendar.

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Tips on libraries


On Monday, February 25, 2019 at 12:33:23 PM UTC+1, Ramon Flamia wrote:
Hi everyone,
having to start a new GWT project, on average complex, which framework / technologies you recommend for the following points:

- MVP architecture (currently using GWTP)
- dependency injection (currently using GIN)
- communication with the server (currently using GWT RPC, provided by GWTP)
- UI (currently using GwtBootstrap3)

I ask this question because it seems to me that all the libraries I have mentioned do not foresee new developments; for the GIN and GWTP part this is not a problem, because these libraries are very stable; instead, the part of UI is the one that worries me the most, as there is no upgrade to version 4 of Bootstrap.

Can't give any recommendation wrt UI, as I never used any 3rd-party library and have only worked on maintaining legacy projects for the last years, or GWTP (always used plain old GWT Places and Activities), but GIN ⇒ Dagger 2 (and replace GIN Assisted Injection with either AutoFactory or AssistedInject), and I'd try to avoid GWT-RPC.
Try to avoid anything based on GWT generators these days, and this includes GWTP. People generally use a generator with GWT Places, but it can trivially be replaced with an annotation processor or hand-written code so it's future-proof (work is already done btw: https://github.com/gwtproject/gwt-places)

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] (Unofficial) elemental2-webassembly release

I understand that it is not related to gwt, but still is interesting to know what's going on around - https://www.youtube.com/watch?v=Qe8UW5543-s
Short description - Blazor is a new SPA framework written on C# which at the end compile everything to the webassembly.

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Tips on libraries

Hi everyone,
having to start a new GWT project, on average complex, which framework / technologies you recommend for the following points:

- MVP architecture (currently using GWTP)
- dependency injection (currently using GIN)
- communication with the server (currently using GWT RPC, provided by GWTP)
- UI (currently using GwtBootstrap3)

I ask this question because it seems to me that all the libraries I have mentioned do not foresee new developments; for the GIN and GWTP part this is not a problem, because these libraries are very stable; instead, the part of UI is the one that worries me the most, as there is no upgrade to version 4 of Bootstrap.

Thanks in advance for your suggestions.

Ramon

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Sunday, February 24, 2019

Re: Annotation processing in Eclipse

On Saturday, February 23, 2019 at 7:03:49 AM UTC-5, Thomas Broyer wrote:
Eclipse annotation processing is known to be broken in many ways...

Yep. I took a look at the logs as Jens suggested and found an exception from the dagger compiler. Eclipse is definitely not doing it right. The dagger processor is being told 'processingOver' twice and, as one might expect, dagger throws an IllegalStateException on the 2nd invocation.

I did find that eclipse allows the order of apt processors to be changed. When I put AutoFactory's first all is good (until eclipse re-orders the list again). This allows me to put together a repeatable test-case for the eclipse folks, should they care to try to address this issue.
 
You may want to disable "in the editor" processing and explicitly run annotation processing by rebuilding the project...

I'm  pretty sure I tried that without success. I'll try it again, though.

Thanks to all for your replies.

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Saturday, February 23, 2019

[ANN] (Unofficial) JsInterop-Base 1.0.0-b2-e6d791f release

The jsInterop-base library contains a set of utilities to implement functionality that
cannot be expressed with Jsinterop alone.


This is an unofficial release to Maven Central under a different groupId.
Please don't bug the original authors. Versions are released on demand.

The only change relative to 1.0.0-b1-e6d791f is that the java source is
included in the main jar rather than only being available in the `-sources` jar.
This was to align with behaviour of the original 1.0.0-RC1 release.

The Maven dependency can be added to your pom.xml via

    <dependency>
      <groupId>org.realityforge.org.realityforge.com.google.jsinterop</groupId>
      <artifactId>base</artifactId>
      <version>1.0.0-b2-e6d791f</version>
    </dependency>

Hope this helps,

Peter Donald

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Seeking advice, migrating from Ant to Maven for GWT App build

On Saturday, February 23, 2019 at 7:31:20 AM UTC-5, Thomas Broyer wrote:

Given your description, you could create fewer Maven modules (I'm not saying you should do it, but you could)
* shared, with common.shared, app_a.shared and app_b.shared
* common-client, as a gwt-lib, with common.client, and depending on shared and shared-sources
* app_a, as a gwt-app, with a dependency on common-client and shared (and shared-sources), though that one is also brought transitively through common-client
* app_b, as a gwt-app, with a dependency on common-client and shared (same as app_a)
* server, as a war, with common.server, app_a.server and app_b.server, and a dependency on shared.

OK, that makes sense to me.  3 modules for the 3 gwt bits, then a single shared and server module for those bits.  I think that would be a viable approach...


Note that you could technically also use a single Maven module mixing client and server code, but this means your server-side dependencies are in your client code classpath (compile and "runtime"), and your client-side dependencies are in your server compile classpath (not runtime if you correctly exclude them from your WAR). If that's how you manage your classpaths with Ant, then it could provide an easier migration path to Maven; see https://github.com/gwtproject/gwt/blob/2.8.2/user/src/com/google/gwt/user/tools/templates/maven/pom.xmlsrc for an example setup (this is the template used by GWT's WebAppCreator)

I feel like using your plugin, then glomming everything into single maven module wouldn't be a prudent approach.  I see the inherent benefit of the multi-module structure, just didn't want to deal with the module-bloat that would have occurred in our app with the approach I was considering (you're 5 module suggestion make a lot more sense to me though).


BTW - my main reason for wanting to move to a maven-based build is to manage the dependent jars in the web-inf/lib directory.

If that's your main driver and you're otherwise OK with Ant, then maybe have a look at Ivy.

I haven't been looking at build systems for the past few years and apparently completely missed Ivy.  It does look to be exactly what I'm really looking for in this case.  Thanks so much for the pointer!

I think you've got me pointed in the right direction.  For this situation it's looking like Ivy is probably the right answer for us at this time.
Thanks so much for taking the time to reply!

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Seeking advice, migrating from Ant to Maven for GWT App build

On Saturday, February 23, 2019 at 12:55:17 PM UTC+1, Ralph Roland wrote:
I'm considering migrating an existing application from being built with Ant, to being built with Maven.
I've been doing a lot of reading and experimenting with the net.ltgt.gwt.maven gwt-maven-plugin but can't seem to wrap my head around the specifics of moving our existing application to the multi-(maven)module model recommended for this plugin.
This application is really two apps in one (each with a separate EntryPoint) plus a third 'common' gwt-module plus supporting common java classes, etc.  Both App-A and App-B GWT modules "inherit" the Common GWT module.  Finally a separate control servlet acts the front-end and returns HTML invoking the correct GWT javascript (App-A or App-B) based on the requested URL.

Our current project structure is:
Project
   src
      com
         foo
            app_a
               client
                  <client-side (GWT related) classes>
                   AppAEntryPoint.java
               server
                  <server-side classes>
               shared
                  <classes shared by client and server packages>
               App_A.gwt.xml
            app_b
               client
                  <client-side (GWT related) classes>
                  AppBEntryPoint.java
               server
                  <server-side classes>
               shared
                  <classes shared by client and server packages>
               App_B.gwt.xml
            common
               client
                  <client-side (GWT related) classes>
               server
                  <server-side classes>
               shared
                  <classes shared by client and server packages>
               Common.gwt.xml (no <entry-point> defined)
   war
      WEB_INF
         lib
            <dependent jars>
My best guess right now for migrating the structure would be to break this into 3 separate projects (App-A, App-B and Common) each with 3 maven modules (App-A-client, App-A-Server, App-A-shared, App-B-client, etc...)  But this seems a bit extreme in that we would end up with 12 distinct Eclipse projects, with code 'spread' across 9 of those.  I feel like if App-A and App-B didn't have their own EntryPoints that I could easily transform this to fit the multi-module archetype structure, but the multiple EntryPoints keeps tripping me up.

Is there something obvious (or not) that I'm missing that would allow our app to 'live' in the (relatively simple) archetyped structure?

Given your description, you could create fewer Maven modules (I'm not saying you should do it, but you could)
* shared, with common.shared, app_a.shared and app_b.shared
* common-client, as a gwt-lib, with common.client, and depending on shared and shared-sources
* app_a, as a gwt-app, with a dependency on common-client and shared (and shared-sources), though that one is also brought transitively through common-client
* app_b, as a gwt-app, with a dependency on common-client and shared (same as app_a)
* server, as a war, with common.server, app_a.server and app_b.server, and a dependency on shared.

Note that you could technically also use a single Maven module mixing client and server code, but this means your server-side dependencies are in your client code classpath (compile and "runtime"), and your client-side dependencies are in your server compile classpath (not runtime if you correctly exclude them from your WAR). If that's how you manage your classpaths with Ant, then it could provide an easier migration path to Maven; see https://github.com/gwtproject/gwt/blob/2.8.2/user/src/com/google/gwt/user/tools/templates/maven/pom.xmlsrc for an example setup (this is the template used by GWT's WebAppCreator)

BTW - my main reason for wanting to move to a maven-based build is to manage the dependent jars in the web-inf/lib directory.

If that's your main driver and you're otherwise OK with Ant, then maybe have a look at Ivy.

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Annotation processing in Eclipse



On Friday, February 22, 2019 at 8:40:27 PM UTC+1, Lars wrote:
Dagger does not play well with the incremental compiler of eclipse - see https://stackoverflow.com/questions/41178320/does-dagger2-annotation-processor-supports-the-eclipse-incremental-compiler
Background is, that the standard annotation processor does only know things from the current runs and this is limited (by design) for an incremental compiler. Whitout some additional (non-standard) components to see the full code or to give the compiler more hints for the dependencies for the generated classes, this works only with a full compile.

Dagger works great with Gradle incremental compilation and annotation processing, so it's not a problem of incremental compilation/processing per se, but likely the bugs that litter the Eclipse compiler (see Jens' answer).

Eclipse annotation processing is known to be broken in many ways, though things are getting better with each release, so first make sure you use the very latest version of Eclipse.
You may want to disable "in the editor" processing and explicitly run annotation processing by rebuilding the project (or something like that; I haven't used Eclipse for years, and I don't let my IDE do anything build-related so 🤷)

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[ANN] (Unofficial) JsInterop-Base 1.0.0-b1-e6d791f release

The jsInterop-base library contains a set of utilities to implement functionality that
cannot be expressed with Jsinterop alone.


This is an unofficial release to Maven Central under a different groupId.
Please don't bug the original authors. Versions are released on demand.

This release contains 2 breaking changes. The removal of the methods:

* JsArrayLike<T>::getAnyAt(int)
* JsPropertyMap<T>::getAny(java.lang.String)

And 6 non breaking changes. 

It should be noted that this is the GWT2.x variant and is not j2cl compatible. In the future there may be a j2cl compatible artifact released if there is demand.

The Maven dependency can be added to your pom.xml via

    <dependency>
      <groupId>org.realityforge.org.realityforge.com.google.jsinterop</groupId>
      <artifactId>base</artifactId>
      <version>1.0.0-b1-e6d791f</version>
    </dependency>

Hope this helps,

Peter Donald

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Friday, February 22, 2019

Seeking advice, migrating from Ant to Maven for GWT App build

I'm considering migrating an existing application from being built with Ant, to being built with Maven.
I've been doing a lot of reading and experimenting with the net.ltgt.gwt.maven gwt-maven-plugin but can't seem to wrap my head around the specifics of moving our existing application to the multi-(maven)module model recommended for this plugin.
This application is really two apps in one (each with a separate EntryPoint) plus a third 'common' gwt-module plus supporting common java classes, etc.  Both App-A and App-B GWT modules "inherit" the Common GWT module.  Finally a separate control servlet acts the front-end and returns HTML invoking the correct GWT javascript (App-A or App-B) based on the requested URL.

Our current project structure is:
Project
   src
      com
         foo
            app_a
               client
                  <client-side (GWT related) classes>
                   AppAEntryPoint.java
               server
                  <server-side classes>
               shared
                  <classes shared by client and server packages>
               App_A.gwt.xml
            app_b
               client
                  <client-side (GWT related) classes>
                  AppBEntryPoint.java
               server
                  <server-side classes>
               shared
                  <classes shared by client and server packages>
               App_B.gwt.xml
            common
               client
                  <client-side (GWT related) classes>
               server
                  <server-side classes>
               shared
                  <classes shared by client and server packages>
               Common.gwt.xml (no <entry-point> defined)
   war
      WEB_INF
         lib
            <dependent jars>
My best guess right now for migrating the structure would be to break this into 3 separate projects (App-A, App-B and Common) each with 3 maven modules (App-A-client, App-A-Server, App-A-shared, App-B-client, etc...)  But this seems a bit extreme in that we would end up with 12 distinct Eclipse projects, with code 'spread' across 9 of those.  I feel like if App-A and App-B didn't have their own EntryPoints that I could easily transform this to fit the multi-module archetype structure, but the multiple EntryPoints keeps tripping me up.

Is there something obvious (or not) that I'm missing that would allow our app to 'live' in the (relatively simple) archetyped structure?

BTW - my main reason for wanting to move to a maven-based build is to manage the dependent jars in the web-inf/lib directory.

Thanks in advance for any pointers!

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Has anybody found a reasonable way to convert *.ui.xml files to web components.

We have many angular developers on the team and they would like to begin to migrate a legacy GWT application (2.7.x) to an NG based application.  RPC has already been replaced using resty-gwt; so now the objective is to begin migrating the client from GWT to Angular.   

Has anyone found an tools to help convert UIBinder widgets/screens into web-components.  

We started by look for gwt compiler options to generate separate html, js, and html files for each *.ui.xml; but there are no such options.    We did find options to generated the bundle sources via -gen/etc.; however these are obviously precompile output used to generate the final js file used to implement the client.  

Any ideas or suggestions would be greatly appreciated!!  

Thank you.

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Annotation processing in Eclipse

Dagger does not play well with the incremental compiler of eclipse - see https://stackoverflow.com/questions/41178320/does-dagger2-annotation-processor-supports-the-eclipse-incremental-compiler
Background is, that the standard annotation processor does only know things from the current runs and this is limited (by design) for an incremental compiler. Whitout some additional (non-standard) components to see the full code or to give the compiler more hints for the dependencies for the generated classes, this works only with a full compile.

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Nalu is released!

Hi Pavlo,

yes, you are right. I am the Owner of the Nalu & Mvp4g project.

First, looking at mvp4g, I would say, that mvp4g is an awesome framework. I used it successfully in many projects in the past. But today, I would not start a new project with mvp4g. Mvp4g (which was origanally created by Pierre-Laurent Coirier) uses heavily GWT generators. So, with J2CL going public it is not the best voice. 

Let's look at mvp4g2. I have rewritten mvp4g and replaced the GWT generators with annotation processors. mvp4g2 is tested with J2CL and will be no show stopper switching from GWT 2.x to J2CL / GWT 3! My intention to create mvp4g2 is to give the mvp4g users an easy upgrade path for the future. As you can see on this page, most of the features of mvp4g has been implemented in mvp4g2: https://github.com/mvp4g/mvp4g2/wiki/Comparision:-Mvp4g-vs.-Mvp4g2, so it might be easy to upgrade. There are only a few changes. (Of course, Nalu will work with J2CL, too!)

Last year I had a discussion with Ahmad and Colin, which - in the end - let me create Nalu. In my opinion, Nalu is a more modern and web-like framework than mvp4g/mvp4g2 is. So, let me compare mvp4g2 with Nalu (the big points):

* history:

In mvp4g2 you have to work with history converters, write them and manage everything. In Nalu, cause it uses the url to route, you have nothing to do for getting  history done. It works out of the box. (Starting with version 1.2.0 you can tell Nalu to avoid using a token in the url). Nalu can work with url or with a hash. It is just a annotation attribute to switch it. So, I would say, Nalu is more web like compared to mvp4g2.

* life cycle:

In mvp4g2, once a presenter view, is created, it will be reused all the time (except for the case you mark the presenter with multiple=true, but in this case you have to create it). In Nalu, a controller (it is the same like a presenter in mvp4g2) has a life cycle: start - activate - mayStop - deactivate - stop. If case it is needed, a controller can be cached (which will reuse the instance of the controller & component). The life cycle thing was one of the points many mvp4g users have missed. Nalu works here like many other GWT frameworks!

* confirmation:

This is a big deal! In mvp4g2, the confirmation is asynchron. I tis possible to do a server call, before to decide to leave the page. In Nalu the mayStop method is synchron! Nalu works here like many other GWT frameworks!

* visible components:

In mvp4g2, you have to deal by yourself where to add views. In Nalu, the framework will do the replacement of the widgets. All you have to do, is to make sure, that a node with the selector id exists. And, with Nalu it is quite easy to work with different application layouts, because the shell is part of the route. I personally prefer the Nalu way to manage the views.

* logging

During development, Nalu logs a lot on the browser console which makes it easier to understand, what the framework does. 

* context

Nalu supports an application wide context (to store application infos) and injects it into every filter, handler and controller.


Nalu and also mvp4g2 have both an event bus, provide features like filters, handlers (controller/presenter without views) and inject instances of the eventbus, the view/component, the context and the router into every controller / presenter.

But, in my opinion Nalu does it with less code and a little bit more elegant, is more like a web application framework than mvp4g2 and I am pretty sure, Nalu will also work on the server side (if there is a plugin). If you would ask me, which one I choose, I would go with Nalu.

If you have any questions, feel free to contact me here: https://gitter.im/Nalukit42/Lobby


If you want to play around with both frameworks, you can generate 

* mvp4g2 projects here: http://www.mvp4g.org/gwt-boot-starter-mvp4g2/GwtBootStarterMvp4g2.html

* Nalu projects here: http://www.mvp4g.org/gwt-boot-starter-nalu/GwtBootStarterNalu.html


More informations about mvp4g2 can be found here: https://github.com/mvp4g/mvp4g2

More informations about Nalu can be found here: https://github.com/NaluKit/nalu


There are many examples projects:

* for mvp4g2: https://github.com/mvp4g/mvp4g2-examples

* and even more for Nalu: https://github.com/nalukit/nalu-examples


Last but not least, I would say, regarding the last month, Nalu is more popular than mvp4g2.

Hope that helps!   

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] (Unofficial) elemental2-webassembly release

Thanks Peter!

On Fri, 22 Feb 2019 at 06:57 Peter Donald <peter@realityforge.org> wrote:
Elemental2 provides type checked access to browser APIs for Java
code. This is done by using closure extern files and generating
JsTypes, which are part of the new JsInterop specification that
is both implemented in GWT and J2CL.


This is an unofficial release to Maven Central under a different groupId
and is completely unofficial so please don't bug the original authors. A
new version is released on demand.

This release includes the first release of elemental2-webassembly. Huzzah!
Please take it for a test drive and report any bugs.

API Changes relative to Elemental2 version 1.0.0-b17-6897368

  7 non breaking changes.
  4 potentially breaking changes.
  2 breaking changes.

The Maven dependencies can be added to your pom.xml via

    <dependency>
      <groupId>org.realityforge.com.google.elemental2</groupId>
      <artifactId>${artifact-id}</artifactId>
      <version>1.0.0-b18-f3472e7</version>
    </dependency>

where artifact-id is one of

* elemental2-core
* elemental2-dom
* elemental2-promise
* elemental2-indexeddb
* elemental2-svg
* elemental2-webgl
* elemental2-media
* elemental2-webstorage
* elemental2-webassembly

Hope this helps,

Peter Donald

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Nalu is released!

Hi Frank, 

I see that you are an owner of Nalu and MVP4G projects. 
Could you please give a small description and advices which one is better for which cases?

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[ANN] (Unofficial) elemental2-webassembly release

Elemental2 provides type checked access to browser APIs for Java
code. This is done by using closure extern files and generating
JsTypes, which are part of the new JsInterop specification that
is both implemented in GWT and J2CL.


This is an unofficial release to Maven Central under a different groupId
and is completely unofficial so please don't bug the original authors. A
new version is released on demand.

This release includes the first release of elemental2-webassembly. Huzzah!
Please take it for a test drive and report any bugs.

API Changes relative to Elemental2 version 1.0.0-b17-6897368

  7 non breaking changes.
  4 potentially breaking changes.
  2 breaking changes.

The Maven dependencies can be added to your pom.xml via

    <dependency>
      <groupId>org.realityforge.com.google.elemental2</groupId>
      <artifactId>${artifact-id}</artifactId>
      <version>1.0.0-b18-f3472e7</version>
    </dependency>

where artifact-id is one of

* elemental2-core
* elemental2-dom
* elemental2-promise
* elemental2-indexeddb
* elemental2-svg
* elemental2-webgl
* elemental2-media
* elemental2-webstorage
* elemental2-webassembly

Hope this helps,

Peter Donald

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Thursday, February 21, 2019

Re: Annotation processing in Eclipse

Have you checked the Eclipse error log window? I know we once examined Dagger2 + AutoFactory and there was some bug in Eclipse JDT that caused internal Eclipse exceptions to escape and thrown during annotation processor execution which in turn stopped generating source files. Maybe that issue is still present or reappeared. 

-- J.

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Annotation processing in Eclipse

It's a slightly off-topic question but possibly an issue familiar to GWT developers.

I'm using Dagger2 and AutoFactory and am quite happy with both. Eclipse, however, does not play nicely with them. After saving any change, I will usually end up with a broken build because Dagger doesn't generate the _Factory classes for the AutoFactory Factory classes. It's acting like the Dagger annotation processor goes first, then AutoFactory's. IOW, when the Dagger processor runs the AutoFactory Factory sources are absent and so Dagger can't generate its code that uses them. IIRC, if any annotation processor generates source files the cycle should be repeated until no new sources are generated. It seems like Eclipse isn't doing that.

I can resolve this by running 'Maven -> Update Project...' so Eclipse's m2e is able to get it right so it seems the incremental build functionality is where the issue lies.

I've tried all three m2e annotation processing settings (auto, experimental, off) with no observable difference in behavior.

My pom does not explicitly declare annotation processor configuration and relies only on auto-discovery.

Are there any Eclipse users out there who are using multiple annotation processors?

Is there a solution to this problem?

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Testing emulated jre classes


On Wednesday, February 13, 2019 at 2:47:10 PM UTC-5, Jens wrote:
 
This can be used to super source classes for GWT compiler that you only use within GwtTestCase and not in your normal app code, e.g. some test library that only works with GWT if you super source some classes.


Thank you. Your explanation makes perfect sense. 

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Sunday, February 17, 2019

[ANNOUNCE] (Unofficial) Elemental2 1.0.0-b17-6897368 packages published to Maven Central

Elemental2 provides type checked access to browser APIs for Java
code. This is done by using closure extern files and generating
JsTypes, which are part of the new JsInterop specification that
is both implemented in GWT and J2CL.

The official Elemental2 project is available via


The Elemental2 project does not yet provide regular releases but
is evolving as the underlying Closure compiler externs evolve and
this can make it difficult to adopt Elemental2 in more traditional
build systems.

Until regular Elemental2 releases start occurring, I have decided
to periodically publish versions of Elemental2 artifacts to maven
central. To avoid conflicts with the official releases the groupId
of the artifacts are prefixed with "org.realityforge." and artifacts
use different versions.

This is completely unofficial so please don't bug the original
Elemental2 authors. A new version will be released when I need a
feature present in newer externs or when I am explicitly asked.

The Maven dependencies published can be added to your pom.xml via

    <dependency>
      <groupId>org.realityforge.com.google.elemental2</groupId>
      <artifactId>${artifact-id}</artifactId>
      <version>1.0.0-b17-6897368</version>
    </dependency>

where artifact-id is one of

* elemental2-core
* elemental2-dom
* elemental2-promise
* elemental2-indexeddb
* elemental2-svg
* elemental2-webgl
* elemental2-media
* elemental2-webstorage

API Changes relative to version 1.0.0-b16-6897368


Hope this helps,

Peter Donald

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Friday, February 15, 2019

Re: Is it possible to mark a class as @JsType native without explicit annotation?

Ok,
just for posterity...

I managed to add jsinterop jars as dependencies. Then I had to change my simple POJO to be jsinterop compatible.
I didn't want to update all call sites but I had to do it anyway (due to constructor changes). If there is a better way let me know.

I thought about @JsProperty but this is also a server side class and it wouldn't work server side. Am I right on this?

Here are the changes:
- Constructor with arguments --> @JsOverlay static factory method
- getters/setter --> @JsOverlay, final

Before:
-----------------------
public class MyClass {
    private String id;

   public MyClass(String id) {
        this.id = id;
   }

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }
}

After:
-------------------------
@JsType(isNative = true, namespace = JsPackage.GLOBAL, name = "Object")
public class MyClass {
    private String id;

  @JsOverlay
   public static create(String id) {
        final MyClass myClass = new MyClass();
        myClass.setId(id);
  }

   @JsOverlay
    public final String getId() {
        return id;
    }

   @JsOverlay
    public final void setId(String id) {
        this.id = id;
    }
}



On Fri, Feb 8, 2019 at 5:09 PM Vassilis Virvilis <vasvir2@gmail.com> wrote:
I thought so...

Nevertheless thanks for answering so swiftly.

   Vassilis

On Fri, Feb 8, 2019 at 5:07 PM Jens <jens.nehlmeier@gmail.com> wrote:

Does that capability exists somehow?

No. You have to create your own class, mark it as JsType and delegate to the class you don't own.

-- J. 

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


--
Vassilis Virvilis


--
Vassilis Virvilis

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.