zvec-java-0.7.0-linux-arm64.jar

<?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>

    <!-- NOTE: the groupId is the reversed zvec.org domain, required for the
         Sonatype Central namespace verification (TXT record on zvec.org).
         The Java package name org.zvec.binding is aligned with the groupId prefix. -->
    <groupId>org.zvec</groupId>
    <artifactId>zvec-java</artifactId>
    <!-- Version tracks the bundled zvec native version (here zvec v0.7.0),
         matching the zvec release scheme. Binding-only fixes bump the third
         segment (rocksdbjni precedent). -->
    <version>0.7.0</version>
    <packaging>jar</packaging>

    <name>zvec-java</name>
    <description>Industrial-grade Java bindings for the Zvec in-process vector database C API (JavaCPP/JNI)</description>
    <url>https://github.com/zvec-ai/zvec-java</url>

    <organization>
        <name>zvec-ai</name>
        <url>https://zvec.org</url>
    </organization>

    <issueManagement>
        <system>GitHub Issues</system>
        <url>https://github.com/zvec-ai/zvec-java/issues</url>
    </issueManagement>

    <licenses>
        <license>
            <name>Apache License, Version 2.0</name>
            <url>https://www.apache.org/licenses/LICENSE-2.0</url>
            <distribution>repo</distribution>
        </license>
    </licenses>

    <developers>
        <developer>
            <name>zvec-java maintainers</name>
            <email>zvec@alibaba-inc.com</email>
            <organization>zvec-ai</organization>
            <organizationUrl>https://github.com/zvec-ai</organizationUrl>
        </developer>
    </developers>

    <scm>
        <connection>scm:git:https://github.com/zvec-ai/zvec-java.git</connection>
        <developerConnection>scm:git:ssh://git@github.com/zvec-ai/zvec-java.git</developerConnection>
        <url>https://github.com/zvec-ai/zvec-java</url>
    </scm>

    <properties>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

        <javacpp.version>1.5.11</javacpp.version>
        <junit.version>5.10.2</junit.version>

        <!-- Location of the Zvec core (git submodule at ./zvec). Override for local
             builds that reuse a sibling checkout, e.g. -Dzvec.home=/path/to/zvec -->
        <zvec.home>${project.basedir}/zvec</zvec.home>
        <zvec.include.path>${zvec.home}/src/include</zvec.include.path>
        <zvec.lib.path>${zvec.home}/build/lib</zvec.lib.path>
        <!-- cppjieba dictionary bundled with the JAR so the `jieba` FTS
             tokenizer works out of the box (mirrors the zvec SDK layout,
             which ships the same files under data/jieba_dict). -->
        <zvec.jieba.dict.path>${zvec.home}/thirdparty/cppjieba/cppjieba-5.6.7/dict</zvec.jieba.dict.path>

        <!-- Auto-detected build platform (e.g. macosx-arm64, linux-x86_64, windows-x86_64) -->
        <javacpp.platform>${os.name}-${os.arch}</javacpp.platform>

        <!-- Maven Central publishing (release profile): keep manual portal
             review by default; CI may pass -Dcentral.autoPublish=true. -->
        <central.autoPublish>false</central.autoPublish>
    </properties>

    <dependencies>
        <!--
            JavaCPP: JNI code generation + cross-platform native loading.
            JavaCPP 1.5.11 is triple-licensed (Apache-2.0 OR GPL-2.0-or-later OR
            GPL-2.0-with-classpath-exception). This project uses it under the
            Apache-2.0 terms, which is compatible with the project license.
        -->
        <dependency>
            <groupId>org.bytedeco</groupId>
            <artifactId>javacpp</artifactId>
            <version>${javacpp.version}</version>
        </dependency>

        <!--
            JUnit 5 for testing. junit-jupiter is the aggregator artifact
            (api + engine + params); it is test-scope only and not distributed.
        -->
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>${junit.version}</version>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <resources>
            <!-- Default resource directory (kept explicit because overriding
                 <resources> replaces the implicit default). -->
            <resource>
                <directory>src/main/resources</directory>
            </resource>
            <!-- Carry the license and attribution notices inside every JAR we
                 publish (Apache-2.0 4(d): the bundled natives are built from
                 the zvec submodule, whose NOTICE ours reproduces verbatim).
                 Declared as a resource rooted at the repository so each file
                 exists exactly once and stays the source of truth. -->
            <resource>
                <directory>${project.basedir}</directory>
                <targetPath>META-INF</targetPath>
                <includes>
                    <include>LICENSE</include>
                    <include>NOTICE</include>
                </includes>
            </resource>
            <!-- Bundle the cppjieba dictionary files from the zvec submodule
                 into the JAR (zvec/jieba_dict/). At runtime Zvec.initialize()
                 extracts them to a cache directory and registers the dir via
                 zvec_set_default_jieba_dict_dir(). maven-resources-plugin
                 silently skips this entry when the directory is absent (e.g.
                 vendor-mode builds without the submodule). -->
            <resource>
                <directory>${zvec.jieba.dict.path}</directory>
                <targetPath>zvec/jieba_dict</targetPath>
                <includes>
                    <include>jieba.dict.utf8</include>
                    <include>hmm_model.utf8</include>
                </includes>
            </resource>
        </resources>
        <plugins>
            <!-- Step 1: pre-compile ONLY the JavaCPP preset config class so the
                 parser (step 2) can load it as an InfoMapper. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.16.0</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
                <executions>
                    <execution>
                        <id>compile-presets</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                        <configuration>
                            <includes>
                                <include>org/zvec/binding/presets/*.java</include>
                            </includes>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

            <!-- JavaCPP: parse c_api.h to generate ZvecNative.java, then generate
                 and compile the JNI glue library (libjnizvec.*). -->
            <plugin>
                <groupId>org.bytedeco</groupId>
                <artifactId>javacpp</artifactId>
                <version>${javacpp.version}</version>
                <configuration>
                    <includePaths>
                        <includePath>${zvec.include.path}</includePath>
                    </includePaths>
                    <linkPaths>
                        <linkPath>${zvec.lib.path}</linkPath>
                    </linkPaths>
                    <copyLibs>true</copyLibs>
                    <copyResources>true</copyResources>
                </configuration>
                <executions>
                    <!-- 2a. Parser: InfoMapper -> generated ZvecNative.java -->
                    <execution>
                        <id>javacpp-parser</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>build</goal>
                        </goals>
                        <configuration>
                            <classOrPackageNames>
                                <classOrPackageName>org.zvec.binding.presets.ZvecConfig</classOrPackageName>
                            </classOrPackageNames>
                            <outputDirectory>${project.build.sourceDirectory}</outputDirectory>
                        </configuration>
                    </execution>
                    <!-- 2b. Generator + Compiler: ZvecNative -> JNI cpp -> libjnizvec.* -->
                    <execution>
                        <id>javacpp-compiler</id>
                        <phase>process-classes</phase>
                        <goals>
                            <goal>build</goal>
                        </goals>
                        <configuration>
                            <classOrPackageNames>
                                <classOrPackageName>org.zvec.binding.ZvecNative</classOrPackageName>
                            </classOrPackageNames>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.2.5</version>
                <configuration>
                    <!-- The JNI glue (jniZvecNative) and zvec_c_api are bundled under
                         target/classes/<platform>/ by the javacpp plugin and loaded from
                         the classpath at runtime; exposing the lib dir also lets the
                         dynamic linker resolve zvec_c_api (@rpath) during local runs. -->
                    <argLine>-Djava.library.path=${zvec.lib.path}</argLine>
                    <environmentVariables>
                        <DYLD_LIBRARY_PATH>${zvec.lib.path}</DYLD_LIBRARY_PATH>
                        <LD_LIBRARY_PATH>${zvec.lib.path}</LD_LIBRARY_PATH>
                    </environmentVariables>
                    <useModulePath>false</useModulePath>
                </configuration>
            </plugin>

            <!-- Main JAR manifest. The automatic module name is declared
                 explicitly because the name JPMS would otherwise derive from
                 the file name is `zvec.java` - legal, but meaningless and at
                 the mercy of the artifactId. Implementation-* let a consumer
                 confirm at runtime which coordinates were actually resolved. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>3.5.1</version>
                <configuration>
                    <archive>
                        <manifestEntries>
                            <Automatic-Module-Name>org.zvec.binding</Automatic-Module-Name>
                            <Implementation-Title>${project.name}</Implementation-Title>
                            <Implementation-Version>${project.version}</Implementation-Version>
                            <Implementation-Vendor>${project.organization.name}</Implementation-Vendor>
                        </manifestEntries>
                    </archive>
                </configuration>
            </plugin>

            <!-- Style gate, invoked as `mvn checkstyle:check` by the CI `lint`
                 job. It is intentionally not bound to a lifecycle phase: the
                 publish pipeline builds inside a manylinux container, and an
                 extra plugin there is an extra way for a release to fail.
                 Declaring it here pins the version (an undeclared
                 `checkstyle:check` resolves whatever the repository metadata
                 currently calls latest) and supplies the configuration to that
                 direct goal invocation. -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
                <version>3.3.1</version>
                <configuration>
                    <configLocation>config/checkstyle.xml</configLocation>
                    <inputEncoding>${project.build.sourceEncoding}</inputEncoding>
                    <consoleOutput>true</consoleOutput>
                    <failsOnError>true</failsOnError>
                    <failOnViolation>true</failOnViolation>
                    <violationSeverity>warning</violationSeverity>
                    <includeTestSourceDirectory>true</includeTestSourceDirectory>
                    <linkXRef>false</linkXRef>
                    <!-- Generated by the JavaCPP parser from c_api.h; it has to
                         stay reproducible, so it is not ours to reformat. -->
                    <excludes>**/ZvecNative.java</excludes>
                </configuration>
            </plugin>

            <!-- Fat jar (example runner + bundled native libs). -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-shade-plugin</artifactId>
                <version>3.5.2</version>
                <executions>
                    <execution>
                        <id>shade-fat-jar</id>
                        <phase>package</phase>
                        <goals>
                            <goal>shade</goal>
                        </goals>
                        <configuration>
                            <transformers>
                                <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                                    <mainClass>org.zvec.binding.examples.BasicExample</mainClass>
                                </transformer>
                            </transformers>
                            <shadedArtifactAttached>true</shadedArtifactAttached>
                            <shadedClassifierName>with-dependencies</shadedClassifierName>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

    <profiles>
        <!-- Maven Central publishing profile: GPG-signed deployment of the
             all-platform main JAR plus sources and javadoc JARs (artifact
             layout follows org.duckdb:duckdb_jdbc). Activate with:
                 mvn deploy -Prelease [-,release-natives] -DskipTests
             `release` publishes the main (all-platform) JAR plus sources and
             javadoc; `release-natives` additionally builds and attaches the
             single-platform classifier JARs and the nolib JAR (CI only, it
             requires every platform's native library to be staged). -->
        <profile>
            <id>release</id>
            <build>
                <plugins>
                    <!-- The shaded with-dependencies JAR is a convenience for
                         running the examples; do not ship it to Central. -->
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-shade-plugin</artifactId>
                        <executions>
                            <execution>
                                <id>shade-fat-jar</id>
                                <phase>none</phase>
                            </execution>
                        </executions>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-source-plugin</artifactId>
                        <version>3.4.0</version>
                        <configuration>
                            <!-- The publish pipeline stages every platform's
                                 natives into src/main/resources, and the
                                 jieba dictionary is a resource as well. The
                                 source plugin sweeps resource directories into
                                 -sources.jar too, which would publish ~120 MB
                                 of binaries that are already inside the main
                                 and classifier JARs. A sources JAR should
                                 carry sources. -->
                            <excludeResources>true</excludeResources>
                        </configuration>
                        <executions>
                            <execution>
                                <id>attach-sources</id>
                                <goals>
                                    <goal>jar-no-fork</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-javadoc-plugin</artifactId>
                        <version>3.6.3</version>
                        <configuration>
                            <doclint>none</doclint>
                            <quiet>true</quiet>
                        </configuration>
                        <executions>
                            <execution>
                                <id>attach-javadocs</id>
                                <goals>
                                    <goal>jar</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-gpg-plugin</artifactId>
                        <version>3.2.8</version>
                        <configuration>
                            <!-- Non-interactive passphrase entry for CI. -->
                            <gpgArguments>
                                <arg>--pinentry-mode</arg>
                                <arg>loopback</arg>
                            </gpgArguments>
                        </configuration>
                        <executions>
                            <execution>
                                <id>sign-artifacts</id>
                                <phase>verify</phase>
                                <goals>
                                    <goal>sign</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
                    <plugin>
                        <groupId>org.sonatype.central</groupId>
                        <artifactId>central-publishing-maven-plugin</artifactId>
                        <version>0.8.0</version>
                        <extensions>true</extensions>
                        <configuration>
                            <!-- Credentials come from the <server id="central">
                                 entry in settings.xml (CENTRAL_TOKEN_USER /
                                 CENTRAL_TOKEN_PASSWORD in CI). -->
                            <publishingServerId>central</publishingServerId>
                            <!-- Keep manual review for now: the bundle stops in
                                 the portal's Deployments page after validation
                                 and is published by clicking "Publish". Flip to
                                 true (or pass -Dcentral.autoPublish=true) once
                                 the pipeline is proven. -->
                            <autoPublish>${central.autoPublish}</autoPublish>
                            <waitUntil>validated</waitUntil>
                        </configuration>
                    </plugin>
                </plugins>
            </build>
        </profile>

        <!-- Extra classifier artifacts (same layout family as
             org.duckdb:duckdb_jdbc): one JAR per platform (classes +
             jieba dict + that platform's natives only) and a nolib JAR
             (classes + dict, no natives). Requires every supported platform's
             native bundle to be staged, which is only the case in the
             publish-jar CI job; the script fails loudly otherwise. -->
        <profile>
            <id>release-natives</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>exec-maven-plugin</artifactId>
                        <version>3.6.3</version>
                        <executions>
                            <execution>
                                <id>package-platform-jars</id>
                                <phase>prepare-package</phase>
                                <goals>
                                    <goal>exec</goal>
                                </goals>
                                <configuration>
                                    <executable>bash</executable>
                                    <arguments>
                                        <argument>${project.basedir}/scripts/package-platform-jars.sh</argument>
                                        <argument>${project.version}</argument>
                                        <argument>--require-all</argument>
                                    </arguments>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                    <plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>build-helper-maven-plugin</artifactId>
                        <version>3.5.0</version>
                        <executions>
                            <execution>
                                <id>attach-platform-jars</id>
                                <phase>package</phase>
                                <goals>
                                    <goal>attach-artifact</goal>
                                </goals>
                                <configuration>
                                    <artifacts>
                                        <artifact>
                                            <file>${project.build.directory}/zvec-java-${project.version}-macosx-arm64.jar</file>
                                            <classifier>macosx-arm64</classifier>
                                            <type>jar</type>
                                        </artifact>
                                        <artifact>
                                            <file>${project.build.directory}/zvec-java-${project.version}-linux-x86_64.jar</file>
                                            <classifier>linux-x86_64</classifier>
                                            <type>jar</type>
                                        </artifact>
                                        <artifact>
                                            <file>${project.build.directory}/zvec-java-${project.version}-linux-arm64.jar</file>
                                            <classifier>linux-arm64</classifier>
                                            <type>jar</type>
                                        </artifact>
                                        <artifact>
                                            <file>${project.build.directory}/zvec-java-${project.version}-windows-x86_64.jar</file>
                                            <classifier>windows-x86_64</classifier>
                                            <type>jar</type>
                                        </artifact>
                                        <artifact>
                                            <file>${project.build.directory}/zvec-java-${project.version}-nolib.jar</file>
                                            <classifier>nolib</classifier>
                                            <type>jar</type>
                                        </artifact>
                                    </artifacts>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>
</project>