Eco system #351
Eco system #351
Conversation
| @@ -0,0 +1,165 @@ | |||
| GWT News | |||
There was a problem hiding this comment.
I might try to investigate if we can automate this, by allowing libraries to publish some RSS feeds to some service where we can fetch and display them, libraries and apps might be able to include some RSS publishing right through the release process like github actions or other means.
There was a problem hiding this comment.
Would be awesome if we can automate this. To start, I think, we can go with a manual solution.
src/main/markdown/eco/add-lib.md
Outdated
| * The Library must be well documented | ||
| * The Library must be deployed to Maven central | ||
| * The Library must be an Open Source project | ||
| * The Library requires a Apache 2 Licence |
There was a problem hiding this comment.
I don't think we need both bullet points - if it must be Apache v2, we don't need the open source license.
With that said, why should Apache v2 be a requirement (closure-compiler has a MPL dependency, for example)? And while it has become less popular to use closed source UI libraries on the web, it seems reasonable that as long as it is labeled accordingly that it be allowed?
There was a problem hiding this comment.
Yes, you are right. I added this because I want to avoid adding paid libraries. I don't want to promote vommercial libraries. So I remove the The Library requires a Apache 2 License.
Done.
src/main/markdown/eco/add-lib.md
Outdated
| We will expect: | ||
|
|
||
| * The Issue must be created by a contributor of the library | ||
| * The Library must be under active development |
There was a problem hiding this comment.
This seems like a tricky requirement - is GWT itself under active development, over the months at a time that no commits are merged? If a project is stable, or is a wrapper for a JS library that has a stable API, can it not be listed?
There was a problem hiding this comment.
I'll change it to something like: The Library must be maintained
Done.
src/main/markdown/eco/add-lib.md
Outdated
|
|
||
| We will expect: | ||
|
|
||
| * The Issue must be created by a contributor of the library |
There was a problem hiding this comment.
What are the concerns here, that someone else might publicize a library that wasn't ready to be showcased?
There was a problem hiding this comment.
Ok, remove it.
Done
src/main/markdown/eco/add-lib.md
Outdated
|
|
||
| We will add or update information on request. | ||
|
|
||
| ## Request for adding Libraries to the Eco System site |
There was a problem hiding this comment.
Maybe generalize "library" to "dependency", so we can discuss frameworks, plugins, etc?
There was a problem hiding this comment.
Good point. I'll switch from library to ** dependency** in general ...
Done
src/main/markdown/eco/archetype.md
Outdated
| For more information visit the archetype at [gwt-maven-springboot-archetype at GitHub](https://github.com/NaluKit/gwt-maven-springboot-archetype) | ||
| and follow the instructions. | ||
|
|
||
| ### domino-cli<a id="create-third-party-nk"></a> |
Co-authored-by: Colin Alworth <colin@vertispan.com>
Co-authored-by: Colin Alworth <colin@vertispan.com>
|
Regarding the discussion in #348 should I remove the eco system news site? |
src/main/markdown/eco/eco-news.md
Outdated
|
|
||
|
|
||
|
|
src/main/markdown/eco/eco-system.md
Outdated
| @@ -0,0 +1,263 @@ | |||
| # GWT Eco System | |||
There was a problem hiding this comment.
| # GWT Eco System | |
| # GWT Ecosystem |
src/main/markdown/eco/eco-system.md
Outdated
| @@ -0,0 +1,263 @@ | |||
| # GWT Eco System | |||
|
|
|||
| Today, the GWT eco system is not only that, what comes with the framework. Usually, projects use a lot of third party | |||
There was a problem hiding this comment.
| Today, the GWT eco system is not only that, what comes with the framework. Usually, projects use a lot of third party | |
| Today, the GWT ecosystem is not only what comes with the framework. Usually, projects use a lot of third party |
src/main/markdown/eco/eco-system.md
Outdated
|
|
||
| First and foremost, GWT is a Java to JavaScript transpiler. The basic idea is to use a type-safe and object oriented | ||
| language to create applications which can ran natively in the browser. During development, developers benefit from the | ||
| existing Java tool chain, powerful IDEs and awesome refactoring abilities. In production the transpiler creates highly |
There was a problem hiding this comment.
| existing Java tool chain, powerful IDEs and awesome refactoring abilities. In production the transpiler creates highly | |
| existing Java toolchain, powerful IDEs and awesome refactoring abilities. In production the transpiler creates highly |
src/main/markdown/eco/eco-system.md
Outdated
|
|
||
| In 2006, as GWT emerges, things were different. JavaScript depends on the browser and Java were in an | ||
| early state of evolution. That's one of the reasons why we have permutations and generators in GWT. Also there no | ||
| third-party-dependencies. Everything had to be provided by the framework. With GWT 2, a lot of new modules like: editor, uibinder, etc. |
There was a problem hiding this comment.
| third-party-dependencies. Everything had to be provided by the framework. With GWT 2, a lot of new modules like: editor, uibinder, etc. | |
| third-party-dependencies. Everything had to be provided by the framework. With GWT 2, a lot of new modules like: editor, uibinder, etc. |
src/main/markdown/eco/eco-system.md
Outdated
| and the gaps of the JavaScript engines in the different browser are no longer a pain point. Third party dependencies add a lot of | ||
| things that GWT does not cover or offer an alternative implementation of existing implementations. | ||
|
|
||
| Also, Google transfers the lead of the GWT project to an Open Source community. |
There was a problem hiding this comment.
| Also, Google transfers the lead of the GWT project to an Open Source community. | |
| Also, Google transferred control of the GWT project to the Open Source community. |
src/main/markdown/eco/eco-system.md
Outdated
| the old groupId **com.google.gwt**, GWT can also be loaded with the new groupId: **org.gwtproject**. Starting from 2.11.0 | ||
| GWT will only be available under the groupId of **org.gwtproject**. | ||
|
|
||
| GWT 2.11.0 will be the first release that requires Java 11! |
There was a problem hiding this comment.
| GWT 2.11.0 will be the first release that requires Java 11! | |
| GWT 2.12.0 will be the first release that requires Java 11! |
src/main/markdown/eco/eco-system.md
Outdated
|
|
||
| GWT 2.11.0 will be the first release that requires Java 11! | ||
|
|
||
| Currently we have started the work on GWT 2.12.0. This release will focus on implementing new Java Language features. See the [roadmap](/oadmap.html) for more information. |
There was a problem hiding this comment.
| Currently we have started the work on GWT 2.12.0. This release will focus on implementing new Java Language features. See the [roadmap](/oadmap.html) for more information. | |
| Currently we have started the work on GWT 2.12.0. This release will focus on implementing new Java Language features. See the [roadmap](/roadmap.html) for more information. |
| amount of legacy applications the community starts to migrate the GWT modules in 2019. These migrated modules no longer | ||
| use generators (instead they are using annotation processors) and JSNI (JavaScript Native Interface). Now, they are | ||
| using JsInterop. On the long term, using this new modules, will enable applications to switch to the new transpiler | ||
| very smoothly. |
There was a problem hiding this comment.
I think this paragraph needs more justification for GWT 2 projects to use the modules.
Specifically:
- Java's principles include keeping projects maintainable over long periods of time: While changes like the addition of JPMS have required some projects to make changes, those are infrequent and usually not too major.
- Likewise, GWT tries to avoid breaking changes, enabling projects to continue to compile old projects using old APIs to still work with new browsers and new Java releases. This cannot always be perfect (code that assumes old browsers obviously will not work), but it will support teams who can update to get security fixes, performance improvements, and new browser support with minimal effort of their own.
- However, this limitation on breaking existing code makes the repository "append-only" - we cannot remove old features easily. For the compiler itself, this is largely not a problem, but for gwt-user, any change might break existing applications. It is more important to support old projects updating in a low- or no-effort manner, than to continue to mutate the APIs of these projects.
- Additionally, there is an unclear dependency between gwt-user.jar and gwt-dev.jar - if a new compiler offers compiled size improvements, it is usually not possible to update only gwt-dev.jar and leave and old, working version of gwt-user.jar. (in contrast, it is usually possible to keep an old version of gwt-servlet.jar, not that we encourage this).
- Instead, moving the "user" code (aka GWT modules) out to separate modules enables teams to keep their runtime code at an older version not tied to the compiler. Maintainers of the modules can likewise experiment with APIs or remove dead code, and regardless of compiler version or implementation, downstream projects can adapt to those changes.
| In 2006, as GWT emerges, things were different. JavaScript depends on the browser and Java were in an | ||
| early state of evolution. That's one of the reasons why we have permutations and generators in GWT. Also there no |
There was a problem hiding this comment.
I don't quite understand "...and Java [was] in an early state of evolution" - is this referring to generators rather than apt? If so, disregard.
There was a problem hiding this comment.
Yeah, that is my intention.
Motivation:
GWT is at least a Java to JavaScript transpiler. One of the resons, that we have modules inside the SDK, is, that in 2006, there were no eco system. The SDK has to offer it to be successful. Looking at the next generation transpiler J2CL, there is no SDK, nor these modules. It is up to the community to ensure, that the modules will work with J2CL. From this point of view, the importance of the GWT eco system increases and is mandatory.
Someone looking for information about 'GWT' will enter 'GWT' and pretty sure will land on this site. And, without any hint of the existing eco system, there will be a lot of information missing. Gathering information about GWT related libraries is not an easy and takes, especially, when you are not familar with the GWT eco system, a lot of time. Form my opinion, the gwtproject.org site is the entry point to the GWT SDK and the GWT eco system.
Changes:
I have added two entries to the navigation:
The news links a site with news related to the GWT SDK, GWT modules & J2CL.
The eco system links to a site with some information about the history of GWT, the GWT modules, releases and third party libraries. There are a few more sites added related to this topic:
Note: I added a few libraries - the libraries I know. The list is not complete and I am happy to add more libraries in case the PR gets accepted.
Compared to #348, this PR makes a different between stuff related to the SDK and the eco system.
And, it adds information of the eco system which, I think, this site is also intended for.