Find the generators without scanning the classpath for them

The plugin used org.reflections to walk every jar on its classpath looking for
subtypes of Generator. That cost about 300 ms of every module's build to
discover five classes, roughly ten times what generating the code itself takes.

Each module that supplies a generator now names it in a service file, in the
form the JDK's own service loading uses, and the plugin reads those. The
constructor still takes the Log, so the file is read directly rather than
through ServiceLoader. org.reflections is no longer a dependency.

Measured on api-area002-v001-com, as the goal's cost above a bare clean: 450 ms
before, 151 ms after. Over a whole reactor build of apis/*, 3811 ms to 2525 ms.

Also restores src/main/resources in the three generator modules. They override
<resources> to pick up LICENCE.md, which silently dropped the directory the
parent declares, so nothing under src/main/resources had ever been packaged
there - which is why the service files did not appear until it was fixed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: CesarCoelho

api-generator/api-generator-maven-plugin/pom.xml

@@ -80,11 +80,6 @@
             <groupId>com.sun.xml.bind</groupId>
             <artifactId>jaxb-core</artifactId>
         </dependency>
-        <dependency>
-            <groupId>org.reflections</groupId>
-            <artifactId>reflections</artifactId>
-            <version>0.9.10</version>
-        </dependency>
         <dependency>
             <groupId>xml-apis</groupId>
             <artifactId>xml-apis</artifactId>
@@ -107,6 +102,11 @@
 
     <build>
         <resources>
+            <!-- Restored: the parent declares it, and overriding <resources> here dropped
+                 it, so nothing under src/main/resources was ever packaged. -->
+            <resource>
+                <directory>${basedir}/src/main/resources</directory>
+            </resource>
             <resource>
                 <directory>${basedir}/..</directory>
                 <includes>

api-generator/api-generator-maven-plugin/src/main/java/esa/mo/tools/stubgen/StubGenerator.java

@@ -24,14 +24,19 @@
 import esa.mo.xsd.util.XmlSpecification;
 import esa.mo.xsd.util.XsdSpecification;
 import java.io.File;
+import java.io.BufferedReader;
 import java.io.IOException;
+import java.io.InputStreamReader;
 import java.lang.reflect.Modifier;
+import java.net.URL;
 import java.util.AbstractMap;
 import java.util.ArrayList;
 import java.util.HashMap;
 import java.util.LinkedList;
 import java.util.List;
 import java.util.Map;
+import java.util.Enumeration;
+import java.util.LinkedHashSet;
 import java.util.Set;
 import javax.xml.bind.JAXBContext;
 import javax.xml.bind.JAXBException;
@@ -42,10 +47,6 @@
 import org.apache.maven.plugins.annotations.LifecyclePhase;
 import org.apache.maven.plugins.annotations.Mojo;
 import org.apache.maven.plugins.annotations.Parameter;
-import org.reflections.Reflections;
-import org.reflections.scanners.SubTypesScanner;
-import org.reflections.util.ClasspathHelper;
-import org.reflections.util.ConfigurationBuilder;
 import w3c.xsd.Schema;
 
 /**
@@ -427,33 +428,83 @@ private static XsdSpecification loadXsdSpecification(final File file) throws IOE
         return new XsdSpecification(file, schema);
     }
 
+    /**
+     * The resource each module supplying generators declares them in, one class name per
+     * line, in the form the JDK's own service loading uses.
+     */
+    private static final String SERVICES = "META-INF/services/" + Generator.class.getName();
+
+    /**
+     * Finds the generators on the classpath.
+     * <p>
+     * Each module that supplies one names it in a service file, and this reads those files.
+     * It used to be found by scanning: every jar on the plugin's classpath was walked for
+     * subtypes of {@link Generator}, which cost around 300 ms of every build to discover
+     * five classes - close to ten times what generating the code itself takes. A module
+     * that supplies a generator already knows it does, so it says so.
+     */
     private void loadGenerators(final org.apache.maven.plugin.logging.Log logger) {
         if (generatorsLoaded) {
             return;
         }
 
         generatorsLoaded = true;
 
-        final Reflections reflections = new Reflections(new ConfigurationBuilder()
-                .setUrls(ClasspathHelper.forClassLoader())
-                .setScanners(new SubTypesScanner()));
+        for (String name : declaredGenerators(logger)) {
+            try {
+                final Class<?> cls = Class.forName(name, true, loader());
+                if (Modifier.isAbstract(cls.getModifiers())) {
+                    continue;
+                }
+                final Generator g = (Generator) cls.getConstructor(new Class[]{
+                    org.apache.maven.plugin.logging.Log.class
+                }).newInstance(new Object[]{logger});
 
-        final Set<Class<? extends Generator>> classes = reflections.getSubTypesOf(Generator.class);
+                GENERATOR_MAP.put(g.getShortName().toLowerCase(), g);
+            } catch (Exception ex) {
+                logger.warn("Could not construct generator : " + name);
+            }
+        }
+    }
 
-        for (Class<? extends Generator> cls : classes) {
-            final int mods = cls.getModifiers();
-            if (!Modifier.isAbstract(mods)) {
-                try {
-                    final Generator g = (Generator) cls.getConstructor(new Class[]{
-                        org.apache.maven.plugin.logging.Log.class
-                    }).newInstance(new Object[]{logger});
+    /**
+     * The plugin's own class loader, which is the realm holding both the plugin and
+     * whatever generators the build supplied to it. The thread's context loader is not it:
+     * inside a Mojo that is Maven's own, and it can see neither.
+     */
+    private static ClassLoader loader() {
+        return StubGenerator.class.getClassLoader();
+    }
 
-                    GENERATOR_MAP.put(g.getShortName().toLowerCase(), g);
-                } catch (Exception ex) {
-                    logger.warn("Could not construct generator : " + cls.getName());
+    /**
+     * @return the class name of every generator declared on the classpath, in the order the
+     * class loader offers them.
+     */
+    private static Set<String> declaredGenerators(
+            final org.apache.maven.plugin.logging.Log logger) {
+        final Set<String> names = new LinkedHashSet<String>();
+        try {
+            final Enumeration<URL> found = loader().getResources(SERVICES);
+            while (found.hasMoreElements()) {
+                final BufferedReader in = new BufferedReader(new InputStreamReader(
+                        found.nextElement().openStream(), "UTF-8"));
+                try {
+                    String line;
+                    while ((line = in.readLine()) != null) {
+                        final int comment = line.indexOf('#');
+                        final String name = (comment < 0 ? line : line.substring(0, comment)).trim();
+                        if (!name.isEmpty()) {
+                            names.add(name);
+                        }
+                    }
+                } finally {
+                    in.close();
                 }
             }
+        } catch (IOException ex) {
+            logger.warn("Could not read the declared generators: " + ex.getMessage());
         }
+        return names;
     }
 
     private void processWithGenerator(final Generator generator,

api-generator/generator-docs/pom.xml

@@ -145,6 +145,11 @@
 
     <build>
         <resources>
+            <!-- Restored: the parent declares it, and overriding <resources> here dropped
+                 it, so nothing under src/main/resources was ever packaged. -->
+            <resource>
+                <directory>${basedir}/src/main/resources</directory>
+            </resource>
             <resource>
                 <directory>${basedir}/..</directory>
                 <includes>

api-generator/generator-docs/src/main/resources/META-INF/services/esa.mo.tools.stubgen.Generator

@@ -0,0 +1,4 @@
+# The generators this module supplies, found by the plugin without scanning the
+# classpath for them. See StubGenerator.loadGenerators.
+esa.mo.tools.stubgen.GeneratorDocx
+esa.mo.tools.stubgen.GeneratorSvg

api-generator/generator-java/pom.xml

@@ -89,6 +89,11 @@
 
     <build>
         <resources>
+            <!-- Restored: the parent declares it, and overriding <resources> here dropped
+                 it, so nothing under src/main/resources was ever packaged. -->
+            <resource>
+                <directory>${basedir}/src/main/resources</directory>
+            </resource>
             <resource>
                 <directory>${basedir}/..</directory>
                 <includes>

api-generator/generator-java/src/main/resources/META-INF/services/esa.mo.tools.stubgen.Generator

@@ -0,0 +1,4 @@
+# The generators this module supplies, found by the plugin without scanning the
+# classpath for them. See StubGenerator.loadGenerators.
+esa.mo.tools.stubgen.GeneratorJava
+esa.mo.tools.stubgen.GeneratorGwt