Is there any way to add source folder?

[turych]

Hi.

I have next:
Button extends BaseButton, BaseButton extends View, View extends BaseView.
Base's classes located in separated folder(some b-logic). Inherited classes contain elemental2 code.
Both have the same package.

Structure:
Shared/com/domain/app/ -> base classes
Web/com/domain/app/ -> Inherited classes

How to concat source directories when I run j2cl:build or watch?
I'm trying to use build-helper-maven-plugin, unsuccessfully.
Maybe there's something I'm missing.

Thanks.

[niloc132]

spurce == source?

The standard maven rules apply here, this plugin just reads how you've configured maven. Your build-helper-maven-plugin might work, but you need to make sure that you are adding those sources early enough in the build, and in such a way that a parent pom (if it exists) can see them.

The conventional way would be for each of Shared/ and Web/ to have a src/main/java/ dir, with com/domain/app/ inside of them. Then, you run the j2cl:watch from the parent pom, so that it can see all of the child projects (though j2cl:build would still run from the Web project, which would depend on Shared). This is what we would strongly suggest, rather than one single project that contains both shared and client (and possibly server) code - j2cl does not have the kind of flexibility that GWT had in this regard.

[turych]

source :)

build-helper-maven-plugin makes sources in target, looks good, but j2cl:build always gets sources from Web/src/main/java/. According to plugin's sources, it always gets project sources from MavenProject.getCompileSourceRoots().

Make parent and child projects is a good idea(I like it), but not for my legacy. I have сyclic dependencies: Web depends on Shared, Shared depends on Web.

Now, we are using GWT, it's solved: in CLI by -classpath; in idea gwt plugin by adding content root.
I'm looking the same solution in Maven. And I don't want to make migration by bazel 😢

[niloc132]

Legacy isn't going to work here - j2cl is much pickier about how it works than GWT is.

GWT is not just a compiler, its a whole build system. The .gwt.xml "module files" help you define the structure of your code, how dependencies work, what packages can be compiled, which packages replace other packages. GWT only runs once, and is fed all of the sources at the same time, compiles each and optimizes them all at once.

J2CL doesn't support any of that, it is just "Feed me source to compile, and the bytecode if its dependencies", the same way that javac itself works. In turn, you run it once on each dependency you rely on and each module in your project (Google encourages that to be as small as a package of classes, much smaller than maven prefers) - done this way, you can compile different modules in parallel, or recompile just one without all the rest. Then, closure-compiler is given all compiled JS and produces either your dev or prod js.

To create this plugin, we had a choice - use it like javac, or build a new GWT around it. Building a new GWT would mean a new .gwt.xml-like file, and either that would have breaking changes, or just one giant j2cl run at the end of the build (like GWT did), which would be slower, use more memory, and not be able to cache results.

Instead, we designed the plugin to behave like how Bazel runs j2cl, where only changed files and their downstream dependents are built. This requires clean maven modules (client/shared/etc) that represent the same basic structure as their GWT modules, and clear separation of what should be compiled and what shouldn't (client/server).

My question to you then: Why do you want to use j2cl? If the performance improvements matter, we have to do it this way, the project structure changes will benefit you by enabling these enhancements in caching, smaller incremental rebuilds. If you aren't interested in that, sticking with GWT almost certainly makes sense (GWT isn't dead, it is improving Java support faster than J2CL is...).

[turych]

It makes more sense to me now. Thanks for your time. 👍