Re: Compilation of a large GWT application?

2017-04-12 Thread Paul Stockley
For development purposes you could try the following in your .gwt.xml file You many or may not be able to get away with the first setting depending on how you structured your css. In our project we tried to minimize the amount of code generation. We have about 250 uibinder files and 300,000

Re: Compilation of a large GWT application?

2017-04-12 Thread Marcin Okraszewski
It turns out, AutoBeans generate 250k lines of code! This is compared to 550k written by us. But this is still just a tip of an iceberg. When we dig further into code generation output, it turns out we have overall 1.5 M lines of code generated, so 3x more than we have written! It is mostly

Re: Compilation of a large GWT application?

2017-04-11 Thread Marcin Okraszewski
Good hint. In our case we don't use GWT-RPC, but AutoBeans for REST. Though looking into compile report, it seems it wasn't best choice either, as it seems to generate a lot of code too :-( Will need to look after a replacement. JsInterop would be best here ... I wish it supported

Re: Compilation of a large GWT application?

2017-04-11 Thread Juan Pablo Gardella
Also check the classes that are used by GWT-RPC. For example if those classes are using List instead of ArrayList for example, will generate more JS output. On Tue, 11 Apr 2017 at 12:13 Jens wrote: > > Our optimized output with collapse all is 23 MB. Things are reused

Re: Compilation of a large GWT application?

2017-04-11 Thread Jens
> Our optimized output with collapse all is 23 MB. Things are reused though, > which is visible in left-over taking 6 MB. > How large is a single permutation (= not using collapse-all)? Our app is roughly 300KLOC and results in roughly 6-7MB optimized JS for a single permutation when doing

Re: Compilation of a large GWT application?

2017-04-11 Thread Marcin Okraszewski
Hi, Thanks. That sounds much more doable. Unfortunately we don't have such natural big logic to extract. Everything is very mych spread around across different views. The views are in fact pretty much separate, to the extent we can compile different set of views for development purposes (super

Re: Compilation of a large GWT application?

2017-04-11 Thread Kirill Prazdnikov
We have detached a complex script projectional editor with completion. The interface was very easy - to provide containing element, context for completion, the script itself and callbacks for saving the scripts. -- You received this message because you are subscribed to the Google Groups "GWT

Re: Compilation of a large GWT application?

2017-04-10 Thread Marcin Okraszewski
That is a nice idea. Actually compiling modules as separate entities was definitely something would helped. ModuleCompiler that was producing gwtar output, but looks like it was dropped in 2.8. Now I wonder if that approach is applicable to us. We have a pretty extensive "common" module,

Re: Compilation of a large GWT application?

2017-04-10 Thread Jens
> As far as I know this will add lots of GWT internal stuff which I not > going to export. Right ? > If you are willing to use master branch you can apply filters during compilation: https://github.com/gwtproject/gwt/commit/9eda5dc418f9bdfef2fd21c6113e48dd10672beb -- J. -- You

Re: Compilation of a large GWT application?

2017-04-10 Thread Daniel Kurka
There is a whitelist / blacklist to control that. On Mon, Apr 10, 2017 at 12:30 PM Kirill Prazdnikov wrote: > As far as I know this will add lots of GWT internal stuff which I not > going to export. Right ? > > понедельник, 10 апреля 2017 г., 21:57:33 UTC+3 пользователь

Re: Compilation of a large GWT application?

2017-04-10 Thread Kirill Prazdnikov
As far as I know this will add lots of GWT internal stuff which I not going to export. Right ? понедельник, 10 апреля 2017 г., 21:57:33 UTC+3 пользователь Daniel Kurka написал: > > If you compile your gwt app with -generateJsInteropExports any @JsType is > accessible in global scope: > >> >>

Re: Compilation of a large GWT application?

2017-04-10 Thread Daniel Kurka
If you compile your gwt app with -generateJsInteropExports any @JsType is accessible in global scope: Exporting app: package foo; @JsType public Bar { public Baz baz = new Baz(); } Consuming JS: new Bar().baz.baz1(); Consuming gwt app ( No need for -generateJsInteropExports):

Re: Compilation of a large GWT application?

2017-04-10 Thread Kirill Prazdnikov
You can also use DOM Elememts as an interop types. -- 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

Re: Compilation of a large GWT application?

2017-04-10 Thread Kirill Prazdnikov
The approach is very simple and easy, you use you detached GWT app like any other JS script. Any GWT app is a JS script. 1st you need to define the interface of the detached module in terms of JsInterop: isNative = true. You can only use Strings, numbers, arrays and isNative = true interfaces.

Re: Compilation of a large GWT application?

2017-04-10 Thread Frank Hossfeld
@Kirill: Do you have an example how the splitting will work? Am Sonntag, 9. April 2017 10:54:50 UTC+2 schrieb Kirill Prazdnikov: > > Think about to split your app into several apps and interop between them > via jsinterop. We did that and detach 1 mb of genersted js app. > > Our app is pretty

Compilation of a large GWT application?

2017-04-09 Thread Kirill Prazdnikov
Think about to split your app into several apps and interop between them via jsinterop. We did that and detach 1 mb of genersted js app. Our app is pretty big, resulting js is 3mb, we use single perm for all browsers and not using gwt i18n. But you can not use any java type to interop

Compilation of a large GWT application?

2017-04-06 Thread Marcin Okraszewski
Hi, We are working with a rather big GWT application. It is currently over 500 thousand lines of code, plus dependencies and code generated from GWT.create(). Our biggest pain is currently RAM usage and compilation time. We are getting close to 16 GB RAM for build, which is big on its own