Hi Thomas, thanks a lot for your insight!
Personally I like the idea of Maven to build small projects and always the same, instead of doing "variant" in Gradle (if I understand it correctly). Building "intermediate" artifacts in Maven is also good for me, KISS 😉Building only one project to content everything I feel like I'm using Ant again 😂At the end the complexity is there, whether you put it into the "intermediate" artifacts or you put it into the Gradle "variant". I'm not sure whether I like the idea of "expect/actual" in Kotlin. I thought we don't need this anymore with Java --> WORA. But now we add such a feature back to the programming language thanks to "multi platform" or "platform specifics. Is that not the wrong place / wrong abstraction to put the "platform specific stuffs"? Is that similar to C++ preprocessor macros? @Joker: do you have real experiences with the Gradle plugin you mentioned? If you think, that it is the plugin to be used, I'll add to my slides... But again I never use it... Thanks, Lofi [email protected] schrieb am Mittwoch, 16. September 2020 um 10:36:32 UTC+2: > > > On Wednesday, September 16, 2020 at 9:48:39 AM UTC+2, [email protected] > wrote: >> >> Hi, thanks for the comment. >> >> There are some Gradle plugins for GWT, which one is the "best"? Sofar I >> only use Maven, so never try Gradle... >> >> Maybe others could also tell which Gradle Plugin should we propose? >> @Thomas Broyer? >> > > I don't use any plugin for GWT in Gradle (configuring JavaExec and Test > tasks "by hand"). > > One thing that no plugin seems to have done yet, is use Gradle variants > <https://docs.gradle.org/current/userguide/variant_model.html> for > *shared* libs to expose the sources to dependent subprojects in the same > build only if/when they need it, and possibly use different dependencies: > in a project with 37 subprojects, the GWT app only transitively depends on > 10 of those subprojects, all of which are shared with the server; and some > of them then add the sources JAR of third-party dependencies to the > GWT-specific classpath. > With Maven, you would either put the <classifier>sources</classifier> > dependency in the server classpath as well (for simplicity), add all the > transitively-needed sources dependencies down to the GWT app module, or > create intermediate artifacts that "aggregate" classes and sources (and > possibly add the gwt.xml), like in > https://github.com/tbroyer/gwt-maven-plugin/issues/127#issuecomment-474338891; > > whereas with Gradle, you can do that in the very same project: > > plugins { > java > id("local.gwt-shared-lib") > } > dependencies { > implementation("org.slf4j:slf4j-api") > implementation("some third party lib") > gwt("some emulation lib for SLF4J") > gwt("adapter lib for the other third-party lib") > } > > > > When the GWT app depends (at any level of transitivity) on that lib, it'll > automatically have 'gwt' dependencies in the classpath when calling GWT > (compilation, code server, tests); the server app will only have the > 'implementation' dependencies in its classpath. > > This works well for an application project at least; it would probably > have to be different for a lib that you intend to deploy to a Maven > repository for others to use; which is why I never formalized this in a > (public) Gradle plugin yet. > Ideally I think we'd want a "java-multiplatform" plugin, similar to > kotlin-multiplatform, to support all of the JVM, J2Cl and/or GWT, and > J2ObjC, but Kotlin has an advantage here: they made it part of the language > itself: https://kotlinlang.org/docs/reference/mpp-connect-to-apis.html > > (sorry for the digression) > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/1cdc952a-c8d7-413e-8d4d-284bad681e2cn%40googlegroups.com.
