niloc132
commented
9 months ago Excellent question, and one that comes up more than I'd like. Here's the "short"/focused version, check out the nitty gritty details in the README (or ask, and I'll elaborate here on any specific points) for the long version...
...The Java we all know and love has backward compatible bytecode, and so can distribute jar files with bytecode in them, and expect that future versions of Java will still be able to use them. This is not true for j2cl - there have been at least a few rounds of backwards-incompatible calling convention changes, and there is no reason to assume there won't be more. As a result, we can't encourage teams to upload jar files containing transpiled JS sources to maven repositories - or if we did, we would somehow need them to update those jar files as each ABI change happened - seems like a non-starter to me.
So instead, we have to recompile those sources from scratch, based on the project's own sources. This means constructing the initial compile-time classpath that was used when that particular project was built - and that means pulling in scope=provided sources, since those were available at compile time.
Why not ignore those and permit the downstream application to manage dependencies, and just make one giant classpath, compiling all at once? This is after all what GWT does - and the Google team who devised that process iterated for many years at improving it, before giving up and moving to J2CL. But look a little closer at that move to J2CL, and you'll see that specifically building small projects separately (and isolated!) across a large dependency graph is what J2CL is good at. On the flip side, J2CL is not a build system like GWT was, and assumes you bring your own build system, and the choices today are maven or bazel. Maven is pretty awful at a lot of things, including being certain about what can and cannot be cached, which is why so many of us maven users get very comfortable with calling mvn clean install for every build - just to be sure.
But that is brutal on build times for j2cl projects, so this plugin effectively has become its own build tool, inside of maven. Loosely modeled around the same principles as bazel and gradle, this plugin tries very hard to build each dependency in its own clean environment, and that means ensuring that it only has its own classpath, rather mushing all the sources and dependencies together into one giant classpath.
This necessarily means reading the pom of each project, and building it as if it were from scratch - provided deps get pulled in to the classpath, even if they won't be there at run time (in this case, this means they won't get passed to closure-compiler to produce the "runtime" js, so they won't be present in the browser).
On the plus side, we don't need/want/use a .gwt.xml file any more, but rely on the project itself having an accurate list of dependencies. The upshot of the deal is that if you don't change your dependency list, but do change sources, we only recompile your sources and all of your dependencies are already built (as long as you don't clean... or as long as you move your build cache out of target/). You can even change some of your dependencies without forcing a rebuild of any of the others, so you only pay for what you change - and if those dependency changes keep some transitive deps, those are also kept without being recompiled.
It sounds like you might have something like recursive dependencies, cycles in your dependency graph, that can never be fully resolved? I understand that while GWT can handle this, it isn't something that this plugin will be capable of. There are forks or other implementations that do just put all of the sources into a single classpath, and that might suit you better, but at the cost of performance for making small changes quickly.
I hope this helps - I can try to take a closer look at exactly what is going wrong next week sometime.
salmonb
treblereel
hi, I'm the maintainer of WebFX, a JavaFX transpiler powered by GWT, and I'm starting to investigate the possibility to move to J2CL using your plugin (thanks for making it 🙏).
A WebFX project is typically structured as follow (this is our simplest demo and I will use it as my first use-case for J2CL). So, this is a Maven multi-modules project, and this structure and all build files are automatically generated and maintained by our CLI from the source code (because WebFX has many modules and it would be too much work to manage them manually). The pom.xml of the main module (that contains the JavaFX application source code) depends on the OpenJFX modules (the open-source implementation of JavaFX), but the
scopeof these dependencies isprovidedbecause this main module is cross-platform and therefore not yet executable (however it successfully compiles with Maven).The other modules are the executable ones, the executable environment being indicated by their suffix:
-openjfx= executables for the desktops using JRE + OpenJFX modules-gluon= executables for the mobiles (Android & iOS native apps built by the Gluon plugin based on GraalVM)-gwt= executable for the web (built by GWT)The pom.xml of the
-openjfxmodule finally provides the OpenJFX modules (indirectly as transitive dependencies ofwebfx-kit-openjfx), but because these modules are not GWT compatible, what WebFX does for the-gwtmodule is to replace them with GWT compatible ones, such aswebfx-kit-javafxbase-emulandwebfx-kit-javafxgraphics-emulas you can see in the pom.xml. With these dependencies finally provided, GWT is happy and successfully compiles the-gwtmodule.So I'm trying now to add this new module:
-j2cl= executable for the web (built by J2CL)and basically do the same as for the
-gwtmodule, but I call J2CL through your plugin instead. However, your plugin seems to try building the OpenJFX modules (despite theprovidedscope) because I'm getting many of these warnings:until it finally ends with:
Our CLI was generating the module.gwt.xml file and was listing all transitive dependencies in pom.xml for the
-gwtmodule, but it looks like it's not needed anymore with J2CL.So is it your plugin that now automatically pulls the transitive dependencies from Maven and pass them to J2CL? Shouldn't the dependencies with
providedscopebe ignored in this process?