slick-codegen-customization-example | code example shows how to setup sbt | Generator Utils library

I think I have this figured out.

The problem in the first case is that, in order to have my ExampleCodeGenerator available in the main build scripts, I place it in the project subdirectory. These files, though, are compiled with a version of the Scala compiler that sbt uses—in this case 2.12.14. In 2.12, scala.Serializable is present, but in 2.13 it was replaced with a type alias. So this, in general, won't work, because I'm run-ing the code with the Scala version of the base project, which can be different, and is in fact 2.13. I'm able to force this 2.12 classes directory into the classpath, but to no avail.

In the second case, my guess is that the Class.forName() being called from SourceCodeGenerator.main is using the class loader of the SourceCodeGenerator object's class, and that loader is an instance of sbt.internal.PluginManagement.PluginClassLoader, a java.net.URLClassLoader subclass that contains all the URLs of the JARs in the (base or build, not sure) project, but not the build project's classes directory URL. So that loader can't find ExampleCodeGenerator.

The solution seems to be what I have usually seen: create another subproject that builds a JAR that the base project depends on. This seems unavoidable.