pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <!-- No <parent>. This repository used to inherit from gudusoft:gsp_java,
       the private library reactor, which is why it could not be built by
       anyone outside Gudu: Maven could not resolve the parent POM. It now
       stands on its own and takes the parser from Gudu's public Maven
       repository, declared below. -->

  <groupId>gudusoft</groupId>
  <artifactId>gsp_demo_java</artifactId>
  <name>Gudu Software Parser for Java Demo</name>
  <description>Gudu Software Parser for Java Demo</description>
  <url>https://www.sqlparser.com</url>
  <version>1.0-SNAPSHOT</version>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
		<project.name>Gudu Software Parser for Java Demo</project.name>
		<project.organization.name>Gudu software</project.organization.name>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
		<maven.build.timestamp.format>yyyy-MMM-dd HH:mm z</maven.build.timestamp.format>
        <!-- Bump this to move every demo to a newer parser. Available versions:
             https://www.sqlparser.com/maven/com/gudusoft/gsqlparser/maven-metadata.xml -->
        <gsp.core.version>4.1.9</gsp.core.version>
    </properties>

    <repositories>
        <!-- A file-based repository inside this checkout, holding the one
             dependency that has no coordinate anywhere public. See
             lib-repo/readme.md for the layout and for why this replaced the
             `system`-scope jars that used to sit in lib/.

             ${project.baseUri} rather than file://${project.basedir}: baseUri
             already yields a well-formed file: URI with the right number of
             slashes on both Unix (file:///home/...) and Windows
             (file:///C:/...), and the .bat workflow runs Maven on Windows.

             Declared first so a local hit costs a filesystem stat instead of a
             404 against a remote that deletes artifacts. Everything it does not
             contain falls through to the two repositories below in order. -->
        <repository>
            <id>in-project-vendored</id>
            <url>${project.baseUri}lib-repo</url>
            <releases><enabled>true</enabled></releases>
            <snapshots><enabled>false</enabled></snapshots>
        </repository>

        <!-- Gudu's public Maven repository. The parser is not on Maven Central. -->
        <repository>
            <id>gudu-public-releases</id>
            <url>https://www.sqlparser.com/maven/</url>
        </repository>
    </repositories>

    <profiles>
        <!-- Default: the published parser from Gudu's public Maven repository.
             This is what makes the repository build for anyone who clones it. -->
        <profile>
            <id>public</id>
            <activation><activeByDefault>true</activeByDefault></activation>
            <dependencies>
                <dependency>
                    <groupId>com.gudusoft</groupId>
                    <artifactId>gsqlparser</artifactId>
                    <version>${gsp.core.version}</version>
                </dependency>
            </dependencies>
        </profile>

        <!-- Library development: run the demos against a parser you just built
             from the gsp_java sources, rather than the published one. The core
             installs under the gudusoft groupId, not com.gudusoft, which is why
             this needs its own profile.

                 cd gsp_java
                 mvn install -N && mvn install -pl gsp_java_core -Pquick_install
                 cd ../gsp_demo_java
                 mvn -Plocal -Dgsp.core.version=<installed version> compile

             This replaces the loop that used to exist when the demos were a
             vendored module of the gsp_java reactor. -->
        <profile>
            <id>local</id>
            <dependencies>
                <dependency>
                    <groupId>gudusoft</groupId>
                    <artifactId>gsqlparser</artifactId>
                    <version>${gsp.core.version}</version>
                </dependency>
            </dependencies>
        </profile>
    </profiles>

    <dependencies>
        <!-- The parser itself. This is the trial build: fully functional for
             evaluation, and enough for every demo here. The public Maven
             version is a three-part number and does not necessarily match the
             four-part product version in the release notes. -->

        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.13.2</version>
            <scope>test</scope>
        </dependency>


        <!-- These two were <scope>system</scope> jars under lib/ until the two
             POMs were merged. Both are on Maven Central, and the vendored
             copies were byte-for-byte identical to what Central serves:

                 sha256 7a43d2d5e488e0dac57a6de0284df4413a4733365239649309c4b693f4e429f9
                        simple-xml-2.7.1.jar
                 sha256 641a4d65ab32fbfdccd9c718e3f83ebc4caabdb5e4fe5b3d51527c5fe692631d
                        fastjson-1.2.83.jar

             so this is the same bytes, resolved instead of committed. Three
             things that did not work before now do: they are included by
             maven-shade-plugin and dependency:copy-dependencies (system-scope
             artifacts are silently skipped by both, which is the whole reason
             the dlineage demo needed a hand-written classpath - issue #46),
             Dependabot can see and patch them, and their transitive
             dependencies resolve rather than going missing at runtime. -->
        <dependency>
            <groupId>org.simpleframework</groupId>
            <artifactId>simple-xml</artifactId>
            <version>2.7.1</version>
        </dependency>

        <!-- https://mvnrepository.com/artifact/com.alibaba/fastjson -->
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>fastjson</artifactId>
            <version>1.2.83</version>
        </dependency>
    <!-- Used only by antiSQLInjectionTest to read batches of SQL out of .rar
         archives, hence test scope. Was lib/junrar-0.7.jar on system scope,
         which Dependabot flagged for four advisories (the worst fixed in
         7.4.1) and could not patch, because a system-scope jar is a file on
         disk rather than something Maven can resolve and upgrade. Now a normal
         Maven Central dependency. -->
    <dependency>
        <groupId>com.github.junrar</groupId>
        <artifactId>junrar</artifactId>
        <version>7.5.10</version>
        <scope>test</scope>
    </dependency>

    <!-- The expression evaluator behind demos/antiSQLInjection (GEval). The jar
         contains ONLY org/boris/expr/**, that is "Boris Expr", not
         tk.pratanumandal:expr4j, which this was previously declared as. That
         coordinate named a completely different library and would have misled
         SBOM and vulnerability tooling into scanning the wrong project, so it is
         corrected here to describe the file that is actually on disk.

         This is the one dependency with no coordinate in any public repository
         - searched and confirmed - so it is served from lib-repo/, a
         file-based Maven repository inside this checkout, declared above. It
         was a <scope>system</scope> jar under lib/ until then, which meant no
         packaging plugin could see it; lib-repo/readme.md has the full
         reasoning. It is a normal compile-scope dependency now, so the
         antiSQLInjection demo no longer needs -Dexec.classpathScope=compile.

         Until 2026/7/27 this repository also carried all 365 of these classes as
         vendored .java under demos/antiSQLInjection/org/boris/expr/, so the
         library was shipped twice and the jar was dead weight. The sources were
         removed; this artifact is now what actually supplies org.boris.expr. -->
    <dependency>
        <groupId>org.boris</groupId>
        <artifactId>expr</artifactId>
        <version>0.0.0-vendored</version>
    </dependency>
        <!-- Used only by commonTest/testXmlXSD.java, hence test scope. Was
             lib/jdom.jar (org.jdom:jdom:1.1) on system scope; EVERY version of
             that coordinate carries a high-severity advisory (org.jdom:jdom
             <= 2.0.2), and the fix is not a version bump but the successor
             artifact org.jdom:jdom2, whose classes live in org.jdom2.*. The
             import in that test was moved across with it. -->
        <dependency>
            <groupId>org.jdom</groupId>
            <artifactId>jdom2</artifactId>
            <version>2.0.6.1</version>
            <scope>test</scope>
        </dependency>
        

        <!-- Carried over from the library-side build when the two demo trees
             were merged: sources under demos/generateLineage need SnakeYAML,
             and the JAXB API left the JDK after Java 8.

             The API stays on the javax.xml.bind namespace, not jakarta.xml.bind:
             the parser calls javax.xml.bind.JAXBContext directly, so 2.3.3 (the
             last javax-namespace release of the API) is a compatibility
             requirement, not a version that has been left to rot.

             jaxb-runtime, though, MUST be 2.3.9 rather than the matching 2.3.3.
             2.3.3's optimised reflection path,
             com.sun.xml.bind.v2.runtime.reflect.opt.Injector, calls
             sun.misc.Unsafe.defineClass, which was removed in JDK 11. On any
             newer JDK it logs

                 SEVERE  java.security.PrivilegedActionException:
                         NoSuchMethodException: sun.misc.Unsafe.defineClass

             and then XML2Model.saveXML fails with a NullPointerException and
             "Output dataflow to xml failed.", so DataFlowAnalyzer's XML
             output silently produced nothing on every JDK this project claims
             to support. Verified on OpenJDK 21: 2.3.3 fails, 2.3.9 writes the
             XML cleanly. Do not "align" these two version numbers. -->
        <dependency>
            <groupId>org.yaml</groupId>
            <artifactId>snakeyaml</artifactId>
            <version>2.2</version>
        </dependency>
        <dependency>
            <groupId>jakarta.xml.bind</groupId>
            <artifactId>jakarta.xml.bind-api</artifactId>
            <version>2.3.3</version>
        </dependency>
        <dependency>
            <groupId>org.glassfish.jaxb</groupId>
            <artifactId>jaxb-runtime</artifactId>
            <version>2.3.9</version>
        </dependency>

    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.13.0</version>
                <configuration>
                    <excludes>
                        <!-- dbConnect used to be excluded here as demos/dbConnect/**.
                             It was a whole Maven project nested inside
                             src/main/java, with its own pom.xml, its own
                             src/main/java and 10 JDBC driver jars, and it was never
                             part of this build. It has since been deleted outright:
                             it needed an API migration against sqlenv.util, which
                             the public parser no longer ships, and its vendored
                             drivers carried 16 unpatchable Dependabot advisories.
                             See the README. Nothing left to exclude. -->

                        <!-- Two demos used to be excluded here, and one still is.
                             gettablecolumns/runGetTableColumn.java and
                             columninspect/ColumnInspect.java both built a
                             gudusoft.dbadapter.T<Vendor>SQLDataSource, out of the vendored
                             lib/sqlflow-exporter.jar, to read table metadata from a running
                             database, so neither could do anything without a live server and
                             a JDBC driver. On 2026-07-28 both were changed to take that
                             metadata offline instead, the vendored jar was dropped, and both
                             joined the normal build. See the README. -->

                        <!-- TGetTableColumn_notUsed.java was excluded here. It
                             redefined myMetaDB / TInfoRecord / SortIgnoreCase,
                             which the retained TGetTableColumn.java in the same
                             package already provides, so it also broke any
                             wildcard compile of that folder, which is how
                             compile_gettablecolumns.bat compiles it. Deleted. -->

                        <!-- DataFlowAnalyzer used to be excluded here, and the reason was
                             circular: it was excluded because pom_dlineage.xml compiled it
                             separately, and pom_dlineage.xml existed to produce a standalone
                             lineage jar. That second POM shared ${project.basedir} with this
                             one, so it also shared target/classes and its incremental-build
                             cleanup wiped out the root build (issue #39), which is why it had
                             to be told to write to target-dlineage/ instead.

                             One POM removes the collision at the source rather than working
                             around it. The class compiles here like every other demo, and
                             maven-shade-plugin below packages it as a standalone executable
                             jar. pom_dlineage.xml is deleted; it had drifted twice in ways
                             nothing caught, missing the JAXB dependency this POM already
                             carried (issue #47) and keeping a <parent> published nowhere.

                             Nothing is excluded from this build any more. -->
                    </excludes>
                    <testExcludes>
                        <!-- commonTest/testDBVendor.java used to be excluded here: it
                             asserted on three TSQLEnv collation fields the published
                             artifact does not expose. It has since been returned to
                             the library, along with the rest of the library-side test
                             tree that was duplicated here. -->

                        <!-- Validates generated XML against
                             ../gsp_java_core/doc/xml/sqlschema_comprehensive.xsd,
                             a path outside this repository. It only resolves when
                             this tree sits inside the library checkout, so it
                             cannot pass standalone. It stays in this repository
                             regardless, because the class it exercises,
                             gudusoft.gsqlparser.demos.visitors.xmlVisitor, is a demo that lives here
                             and not in the library. -->
                        <testExclude>gudusoft/gsqlparser/visitorsTest/XmlSchemaValidationTest.java</testExclude>
                        <!-- TestRunner exists only to run the class above, and
                             referencing it would drag it back in through javac's
                             implicit compilation regardless of the exclude. -->
                        <testExclude>gudusoft/gsqlparser/visitorsTest/TestRunner.java</testExclude>
                    </testExcludes>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>exec-maven-plugin</artifactId>
                <version>3.1.1</version>
            </plugin>

            <!-- Packages DataFlowAnalyzer as a standalone lineage tool:
                 target/gsp_demo_java-1.0-SNAPSHOT-dlineage.jar, an executable
                 uber jar with every runtime dependency inside it. This replaces
                 pom_dlineage.xml, which produced a jar holding one .class file
                 and left the user to assemble a classpath by hand - the
                 command the README gave for that pointed at external_lib/, a
                 directory only the Windows .bat route ever creates, so it could
                 not work for anyone following the Maven instructions
                 (issue #46). `java -jar` needs no classpath at all, and the
                 documented command now contains no version number, which
                 matters because the parser's filename changes on every release
                 and Gudu's repository deletes the old ones.

                 It attaches as a classifier alongside the ordinary jar rather
                 than replacing it, so the normal build output is untouched. The
                 uber jar carries every demo class, not just this one, so
                 `java -cp <it> <any.MainClass>` also works. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-shade-plugin</artifactId>
                <version>3.5.3</version>
                <executions>
                    <execution>
                        <id>dlineage-standalone</id>
                        <phase>package</phase>
                        <goals><goal>shade</goal></goals>
                        <configuration>
                            <shadedArtifactAttached>true</shadedArtifactAttached>
                            <shadedClassifierName>dlineage</shadedClassifierName>
                            <!-- Without this, shade rewrites pom.xml into a
                                 dependency-reduced-pom.xml in the project root
                                 and hands that to anything downstream. There is
                                 nothing downstream here, and a generated POM
                                 appearing next to the real one is pure
                                 confusion. -->
                            <createDependencyReducedPom>false</createDependencyReducedPom>
                            <transformers>
                                <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                                    <mainClass>gudusoft.gsqlparser.demos.dlineage.DataFlowAnalyzer</mainClass>
                                </transformer>
                                <!-- Required, not optional. JAXB finds its
                                     implementation through
                                     META-INF/services/javax.xml.bind.JAXBContext,
                                     and several dependencies ship a file at
                                     that same path. Without merging them, one
                                     silently overwrites the others inside the
                                     uber jar and DataFlowAnalyzer dies at
                                     XML2Model.saveXML with the same
                                     NoClassDefFoundError as issue #47 - with
                                     jaxb-runtime present the whole time. -->
                                <transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
                            </transformers>
                            <filters>
                                <filter>
                                    <artifact>*:*</artifact>
                                    <excludes>
                                        <!-- Signed jars carry signatures over
                                             their own contents. Repacking
                                             invalidates them, and a stale
                                             signature block is a
                                             SecurityException at class load,
                                             not a warning. -->
                                        <exclude>META-INF/*.SF</exclude>
                                        <exclude>META-INF/*.DSA</exclude>
                                        <exclude>META-INF/*.RSA</exclude>
                                        <exclude>module-info.class</exclude>
                                    </excludes>
                                </filter>
                            </filters>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

</project>