Creating More Granular Targets for Elemental2

[jDramaix]

Dear Elemental2 Contributors and Users,

We're considering a refactor of Elemental2 to create more granular targets by moving some externs files out of elemental2-dom. The goal is to separate APIs that can be used in any JavaScript runtime environment (like Node.js) from those specific to the browser.

We're keen to hear your thoughts on this proposal, so please share your feedback.

Impact on Users

This change will affect the target/jar and Java package where certain APIs are defined.

For example, users currently depend on elemental2-dom to access the console API, available under the elemental2.dom Java package. If we move the console API to its own elemental2-console library, users will need to:

• Add the new elemental2-console.jar to their project dependencies.
• Change some imports to the new elemental2.console Java package.

[mollyibot]

@niloc132

[gkdn]

also @treblereel @zbynek

[gkdn]

As a summary for contributors:
Granular targets are generally nice and avoid problems around running in different environments however it will be breaking change and might be little bit more fragile.
So we are looking for your feedback.

[treblereel]

@gkdn @jDramaix Breaking changes are never good, but if it's a condition for moving forward, I'm in.

[gkdn]

The main piece here is, if we don't do it now probably we will never do it. We can survive either way but we will keep accumulating more externs into the "dom" package or depend on it on almost anything newly added.
From our side, breaking change doesn't cause problems for our monorepo but major implication will be on the open-source side (hence the thread)

[zbynek]

How many new artifacts are you planning to add? Would it make sense to keep one top level artifact that depends on all the new ones and provides a gwt.xml file that inherits all the new modules?

[gkdn]

We are not planning on something massive; current rough plan is adding couple of extra specific ones and maybe also something to sit in between core and dom to catch small things that doesn't warrant their own package.
I don't think there will be an issue having top level artifact for GWT BUT with our refactoring, the packages for some classes will change.