GWT module per component (to allow individual use)

[zaunt]

I have generated a custom GWT module definition for each component. This makes it possible for users to use individual components rather than being forced to take all the components. Using individual components can reduce compile times, as GWT only compiles source that is actually referenced.

A further improvement would be to move the component CSS into public folders under each component. I have not done that in this pull request, as I wanted to keep it simple and focused on just the module definitions.

I think it would also be possible to remove some of the interdependencies between modules. For example, the Utils module (package) currently has dependencies on CLDR (~23MB jar), NumberFormat, Collapsible, Forms, Popover, Style and Tree. A dependency like Utils to Tree can be severed by moving ParentTreeItem out of Utils into Tree. This would be a breaking change, so I have not made it or any other code changes.

The biggest culprit in terms of compile times is the reference to the CLDR. It adds ~15 seconds to each compilation on my machine. It might be worth breaking the connection (e.g. with your own interfaces and adapters) to make the CLDR optional.

[niloc132]

CLDR is certainly a problem by itself, but one that we're working towards a specific solution for, to offer one dependency per locale, so that you only get the locales you use (very few apps, if any, require all possible locales, the vast majority are probably 10 or less). The limitations we are under in fixing that is also making it work well in J2CL, and Closure-Compiler has been giving us some trouble in producing well-optimized output.

Aside from CLDR, how much of a difference does this patch make? If it isn't a huge difference (as CLDR certainly is), then I suspect that this is far more trouble than it is worth, to maintain and test each of these (a gwt Precompile run or the like should be added for each individually, to be sure it builds on its own). Additionally, if this is a problem, it will return in J2CL which doesn't use .gwt.xml files, and the correct answer there is to break each of these into its own separate maven module, resulting Jar file. If you take that approach, the gwt-maven-plugin will emit the .gwt.xml from pom dependencies.

[vegegoku]

I do agree with @niloc132 , if the CLDR is the bulk of the issue then I would prefer to fix that part instead, and I would avoid this complexity which does not help in case of J2CL.

[zaunt]

Fixing the problems with CLDR upstream would be preferable if you have influence or control over that project.

I found that having individual components did make a small difference to compile times—a couple of seconds, perhaps, depending on which components you use. Most of the components have interdependencies, so the advantage isn't much under normal use. If the component library grows significantly larger then it might become worthwhile.

Another reason I sent the pull request was that I thought you might be planning to do something similar yourselves, e.g. to reduce the amount of static resources being output (#161, #254) and I thought I might save you some time.

I agree with your thinking that, as it stands, the overheads of maintaining the module definitions probably outweigh the benefits. (Although module definitions can be generated automatically—I used ArchUnit to calculate the dependencies).

I'll close this pull request. Thanks for considering it.

[vegegoku]

The load of static resources is definitely something we want to look at and enhance ..we would prefer to inject only resources for used components and thats why we started the split of css for each component..but this is still a WIP