a fast, scalable, multi-language and extensible build system
auke-/gerrit-code-review-plugin 0
Gerrit SCM plugin for Jenkins CI
Starting fresh on building GWT projects with Maven
Annotation processor to create immutable objects and builders. Feels like Guava's immutable collections but for regular value objects. JSON, Jackson, Gson, JAX-RS integrations included
OpenTracing Java JAX-RS instrumentation
A utility class which aids in generating Java source files.
:sailboat: Build container images for your Java applications.
A repository for Micronaut and GraphQL integrations
Repository to investigate Micronaut GRPC on Graal
auke-/protoc-jar-maven-plugin 0
Protocol Buffers protobuf maven plugin - based on protoc-jar multi-platform executable protoc JAR
PR opened codegen-io/wi-suwiml
Bumps jackson.version
from 2.10.2 to 2.12.1.
Updates jackson-annotations
from 2.10.2 to 2.12.1
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/FasterXML/jackson/commits">compare view</a></li>
</ul>
</details>
<br />
Updates jackson-databind
from 2.10.2 to 2.12.1
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/FasterXML/jackson/commits">compare view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase
.
<details> <summary>Dependabot commands and options</summary> <br />
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebase
will rebase this PR@dependabot recreate
will recreate this PR, overwriting any edits that have been made to it@dependabot merge
will merge this PR after your CI passes on it@dependabot squash and merge
will squash and merge this PR after your CI passes on it@dependabot cancel merge
will cancel a previously requested merge and block automerging@dependabot reopen
will reopen this PR if it is closed@dependabot close
will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major version
will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor version
will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependency
will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)@dependabot use these labels
will set the current labels as the default for future PRs for this repo and language@dependabot use these reviewers
will set the current reviewers as the default for future PRs for this repo and language@dependabot use these assignees
will set the current assignees as the default for future PRs for this repo and language@dependabot use this milestone
will set the current milestone as the default for future PRs for this repo and language
You can disable automated security fix PRs for this repo from the Security Alerts page.
</details>
pr created time in 9 days
create barnchcodegen-io/wi-suwiml
branch : dependabot/maven/jackson.version-2.12.1
created branch time in 9 days
issue commenttbroyer/gwt-maven-plugin
DevMode, `gwt-lib` dependency and re-compiling changes
Sorry to spam this issue (isn't really a separate issue) but in case somebody ran into the same issue:
IntelliJ won't import dependencies if they are using with the
gwt-lib
type. To fix this, one has to go toFIle -> Settings -> Maven -> Importing
and addgwt-lib
to the list of automatically imported dependencies.
If we call it a problem then it's still present. I fugured out that the NPE happens i.e. if you mess up the dependencies in your pom.xml with two entries for the same dependency (one with type gwt-lib and the second without any classifier). The plugin version I used for that is 1.0.0, GWT version 2.9.0, maven 3.6.3.
...just wanted to give my two cents here if someone comes by with the same problem.
comment created time in 25 days
push eventtbroyer/gwt-maven-plugin
commit sha 51408d517581beed615b7228993e6beccbdb3f24
Restore automatic snapshot deployment on push
push time in a month
push eventtbroyer/gwt-maven-plugin
commit sha 4480157bd8482337cdc0bf0439fc1ba31a30434d
Remove leftovers from the Travis builds
commit sha 581df28671fba5bf4e9fecd7c6310b2c2021d6be
Take main→master rename into account
push time in a month
issue closedtbroyer/gwt-maven-plugin
I haven't tried this, but I wonder:
Is the Maven goal for DevMode working with GWT 2.9.0 , or is it suffering from the known GWT 2.9.x build classpath symptoms as the ones mentioned under (https://github.com/gwtproject/gwt/issues/9720) and the referenced issues
closed time in a month
eliasbalasisissue commenttbroyer/gwt-maven-plugin
Thanks for confirming.
I was referring to "Super DevMode" not standard "DevMode", which I am using via "Google Plugin for Eclipse" but I have to agree that even though "codeserver" is not as simple it at least bypasses the Jetty runtime classpath issues.
comment created time in a month
issue commenttbroyer/gwt-maven-plugin
Don't use DevMode except for static files in standalone / client-only apps, it's as simple as that: https://tbroyer.github.io/gwt-maven-plugin/codeserver.html
But to answer your question, given that this plugin only runs GWT in forked JVMs, without any modification or even classpath/classloader tricks, then yes it suffers from the same limitations. The advice above applies to GWT generally, whether run through this plugin or anything else (Ant, Gradle, your IDE, etc.)
comment created time in a month
issue openedtbroyer/gwt-maven-plugin
I haven't tried this, but I wonder:
Is the Maven goal for DevMode working with GWT 2.9.0 , or is it suffering from the known GWT 2.9.x build classpath symptoms as the ones mentioned under (https://github.com/gwtproject/gwt/issues/9720) and the referenced issues
created time in a month
push eventtbroyer/gwt-maven-plugin
commit sha 8654f89297f15988110ce75db1f778fa73b6b812
Attach IT tests build logs to GitHub Actions jobs
push time in 2 months
push eventtbroyer/gwt-maven-plugin
commit sha 43477b47b29bdfd9f79f4602b6985b902db19e95
Switch from Travis to GitHub Actions Add a Windows job, and use JDK 15 rather than 14. Only test each GWT version with a single JDK.
commit sha 8572dcd5c03c32bc0dd728a69be97428e63bc720
Update JUnit to 4.13.1
push time in 2 months
push eventtbroyer/gwt-maven-plugin
commit sha 9f271a6964e5ff2f44e93c1cc3d3ca67d46330af
Switch from Travis to GitHub Actions Add a Windows job, and use JDK 15 rather than 14. Only test each GWT version with a single JDK.
commit sha 239172e4fad3b78912ecdf21401e0c91af601e78
Update JUnit to 4.13.1
push time in 2 months
push eventtbroyer/gwt-maven-plugin
commit sha 4f49dc05615419b4ea111710af2299cf75632405
Update JUnit to 4.13.1
push time in 2 months
push eventtbroyer/gwt-maven-plugin
commit sha c300e470b5c449b8a1259311060f871400ab0d77
Switch from Travis to GitHub Actions Add a Windows job, and use JDK 15 rather than 14. Only test each GWT version with a single JDK.
push time in 2 months
issue commenttbroyer/gwt-maven-plugin
How to generate rpc and i18nMessage classes using your plugin?
That should be clearly stated in the documentation ! This is a very common usage.
comment created time in 2 months
issue commenttbroyer/gwt-maven-plugin
Integration with GWT Eclipse Plugin seems partially broken
plugin is 99% IDE-agnostic This confirms my original suspicion that the plugin is not meant to work with "GWT Eclipse Plugin".
I agree, it is a GWT Eclipse Plugin issue.
Thanks for the advice, I will try to make my projects IDE-agnostic.
comment created time in 3 months
issue closedtbroyer/gwt-maven-plugin
Integration with GWT Eclipse Plugin seems partially broken
This is a very good directional shift towards better structured GWT projects.
However, the compatibility with "GWT Eclipse Plugin" seems partially broken.
Projects built with this plugin are still recognized by "GWT Eclipse Plugin" but somehow the WAR source files are not copied to the running area.
Would it be correct to assume that due the change in direction this plugin is not meant to work with "GWT Eclipse Plugin"? If yes, then this will disappoint many supporters of "GWT Eclipse Plugin", myself included.
I am very well aware of the runtime classpath issues caused by strong dependency of "gwt-dev" to hardcoded version of "Jetty" and frankly this will always be a problem, with or without use of "GWT Eclipse Plugin". Yet, I believe "GWT Eclipse Plugin" is still useful.
closed time in 3 months
eliasbalasisissue commenttbroyer/gwt-maven-plugin
Integration with GWT Eclipse Plugin seems partially broken
Regarding your attached project: the project is not a gwt-app
, or at least it's "not only" a gwt-app: it includes an src/main/webapp
that no plugin is going to use (the maven-war-plugin is not bound to any phase, so its configuration is mostly useless, unless you specifically call its goals from the command line, such as mvn war:war
, but then it'll conflict with the gwt:compile
and/or gwt:package-app
goals.
This probably explains why it doesn't quite "work" in Eclipse either.
comment created time in 3 months
issue commenttbroyer/gwt-maven-plugin
Integration with GWT Eclipse Plugin seems partially broken
What I'm saying is that this plugin is 99% IDE-agnostic: the only exception is this file. On the other hand, the GWT Eclipse Plugin has specific code to handle projects using this plugin.
Also, once you've imported the project into Eclipse, you're not using the Maven plugin anymore; the "Run as..." actions are purely Eclipse things, and I have zero idea what they're doing and how they work.
So this is 100% a GWT Eclipse Plugin issue.
BTW, the GWT Eclipse Plugin is a one-man project that hasn't been maintained for more than 2 years now.
If I had one advice, it would be to try to make your projects IDE-agnostic; Gradle makes this easier, but there are ways to do it with Maven too (and this plugin tries to make it easy/easier): https://github.com/tbroyer/gwt-maven-archetypes (you'll notice that the Tomcat Maven Plugin is unmaintained too, so use Jetty, despite the necessary hacks to make it work in a reactor build, or enjoy the Maven limitations and mvn install
your modules before you can call a plugin, such as Cargo or whatever you need to run your web server, in a specific submodule)
comment created time in 3 months
issue commenttbroyer/gwt-maven-plugin
Integration with GWT Eclipse Plugin seems partially broken
Well said.
Unfortunately, I cannot ask "GWT Eclipse Plugin" team to investigate an integration problem with a solution from another vendor, I am certain they will send me back to you, or some teams coordination quite difficult to establish will be required.
Equally, I appreciate this is not your area of responsibility either.
I think I will stay with the legacy "GWT Maven plugin" for now, which does work with "GWT Eclipse Plugin".
comment created time in 3 months
issue commenttbroyer/gwt-maven-plugin
Integration with GWT Eclipse Plugin seems partially broken
I'll have a look at your reproducer but this issue should be in the GWT Eclipse Plugin issue tracker, this is where IDE integration is done.
comment created time in 3 months
issue commenttbroyer/gwt-maven-plugin
Integration with GWT Eclipse Plugin seems partially broken
test-GWT.zip Here is a set of Maven projects I prepared which demonstrates the behavior of both Maven GWT plugins. You can import this in Eclipse of recent version (I used 4.14) with "GWT Eclipse Plugin" installed and "Run As / GWT Development mode with Jetty". Notice that the "test.GWT.legacy" project runs as expected but the "test.GWT.tbroyer" project gets recognized by "GWT Eclipse Plugin" but doesn't deliver the required "index.html" file.
comment created time in 3 months
issue openedtbroyer/gwt-maven-plugin
Integration with GWT Eclipse Plugin seems partially broken
This is a very good directional shift towards better structured GWT projects.
However, the compatibility with "GWT Eclipse Plugin" seems partially broken.
Projects built with this plugin are still recognized by "GWT Eclipse Plugin" but somehow the WAR source files are not copied to the running area.
Would it be correct to assume that due the change in direction this plugin is not meant to work with "GWT Eclipse Plugin"? If yes, then this will disappoint many supporters of "GWT Eclipse Plugin", myself included.
I am very well aware of the runtime classpath issues caused by strong dependency of "gwt-dev" to hardcoded version of "Jetty". Yet, I believe "GWT Eclipse Plugin" is still useful.
created time in 3 months