Add support for build-time transforms

[PaintNinja]

Currently FG7 supports AccessTransformers and Facade through dedicated code paths that run against the Minecraft dependency, along with a separate AT Gradle plugin for applying ATs to other dependencies.

I'd like to request the ability to transform my own mod code at build-time, ideally with some kind of API exposed so that anyone can write a build-time transformer to apply to their own mods. The API should give me the original source file, the compiled bytecode (ClassFile API ClassModel?) and a way of changing the bytecode for each class I'm interested in.

There's this plugin as an existing solution, but it doesn't work with module-info files, relies on JDK internals and uses an ASM visitor API which I'm not keen on.

This would make some global runtime transformers unnecessary and expand what mods could do by allowing direct access to JVM-exclusive features.

[LexManos]

AccessTransformers/Facade are garily generic, we've just written them into FG to make things easier. We could of implemented them as Artrifact Transformers. As the main reason we need to do mavenizer the way we do is because we're generating the actifacts from nothing (which Transformers dont support) and we want source access (which transformers say they support but they dont)
We could expose a simpler interface for arbitrary post processors on the classfiles for dependencies, but thats a different task.

For the task that you want, the 'proper' way to it in gradle is to write our own task that takes the jar output as a RegularFileProperty, like we do in renamer and the sources as a FileCollection.

We could expose a generic JavaExec task that passes those around if you want to write your post processor as an executable jar.

However, it might be feasible to use the com.sun.source.util.Trees API to gain access to the raw source code from an AP. The whole trees package is Exported so in theory 'public' enough to be used.

Specifically:

public class SourceCodeProcessor extends AbstractProcessor {
    private Trees trees;

    @Override
    public synchronized void init(ProcessingEnvironment processingEnv) {
        super.init(processingEnv);
        this.trees = Trees.instance(processingEnv);
    }

    @Override
    public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
        for (Element element : roundEnv.getElementsAnnotatedWith(MyAnnotation.class)) {
            TreePath treePath = trees.getPath(element);
            if (treePath != null)
                var source = treePath.getCompilationUnit().getSourceFile().getCharContent(true);
        }
        return true;
    }
}

See discord for a zip with full runnable example.

That seems to grab the entire source file. Perhaps this is something feasible for what we've been wanting?
This does have the limitations we've spoken about. As in not being able to encode the data into the module-info file. But perhaps we could combine the two? Use an AP, output 'deps.lst' and then a post-processing task (like renamer) that edits the module-info.class file at build time.
We would still need the slow path at dev time to read the deps.lst file. But could have the fast baked path at runtime.