... actually I feel that doing platform specific stuffs in my code it's not the way.
Putting platform specific stuffs in the code mixes the separation of concern, IMHO...
lofid...@gmail.com schrieb am Mittwoch, 16. September 2020 um 18:21:41 UTC+2:
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,Lofit.br...@gmail.com schrieb am Mittwoch, 16. September 2020 um 10:36:32 UTC+2:
On Wednesday, September 16, 2020 at 9:48:39 AM UTC+2, lofid...@gmail.com 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 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:
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@example.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/2ecfd469-9a66-4e34-a139-f43cb1e59b84n%40googlegroups.com.
Post a Comment