pom.xml

<!--
SPDX-FileCopyrightText: 2026 Bernard Ladenthin <bernard.ladenthin@gmail.com>

SPDX-License-Identifier: MIT
-->

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

	<!--
		Aggregator / parent POM. Carries no code — it only groups the modules and holds the
		single shared <version>, which every module inherits (so the core net.ladenthin:llama
		and net.ladenthin:llama-langchain4j always ship in lockstep by construction). The core
		artifact keeps its coordinates net.ladenthin:llama (the `llama` module); consumers are
		unaffected by the directory move.
	-->
	<groupId>net.ladenthin</groupId>
	<artifactId>llama-parent</artifactId>
	<version>6.0.0</version>
	<packaging>pom</packaging>

	<name>${project.groupId}:${project.artifactId}</name>
	<description>Aggregator POM for java-llama.cpp: the native JNI binding
		(net.ladenthin:llama) and its sibling integrations.</description>
	<url>https://github.com/bernardladenthin/java-llama.cpp</url>

	<licenses>
		<license>
			<name>MIT License</name>
			<url>https://www.opensource.org/licenses/mit-license.php</url>
			<distribution>repo</distribution>
		</license>
	</licenses>

	<developers>
		<developer>
			<name>Bernard Ladenthin</name>
			<organizationUrl>https://github.com/bernardladenthin</organizationUrl>
		</developer>
	</developers>

	<scm>
		<connection>scm:git:https://github.com/bernardladenthin/java-llama.cpp.git</connection>
		<developerConnection>scm:git:https://github.com/bernardladenthin/java-llama.cpp.git</developerConnection>
		<url>https://github.com/bernardladenthin/java-llama.cpp/tree/main</url>
	</scm>

	<distributionManagement>
		<snapshotRepository>
			<id>central</id>
			<url>https://central.sonatype.com/repository/maven-snapshots/</url>
		</snapshotRepository>
	</distributionManagement>

	<properties>
		<!--
			The Jackson line, stated once for every module. `llama` uses jackson-databind directly;
			`llama-langchain4j` gets jackson transitively through langchain4j-core, which pulled an
			older jackson-core past a published advisory (two HIGH Dependabot alerts, 2026-10-11)
			because nothing managed it there. The BOM import below pins the whole family for every
			module, so a transitive jackson can no longer be older than this.
		-->
		<jackson.version>2.22.4</jackson.version>
	</properties>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>com.fasterxml.jackson</groupId>
				<artifactId>jackson-bom</artifactId>
				<version>${jackson.version}</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
		</dependencies>
	</dependencyManagement>

	<modules>
		<module>llama</module>
		<module>llama-langchain4j</module>
		<module>llama-kotlin</module>
		<module>llama-ffm</module>
		<module>llama-platform</module>
	</modules>

	<build>
		<!--
			The plugin versions more than one module uses, stated once. Every module inherits them, so a
			module names such a plugin without a version; a plugin only one module uses stays pinned in
			that module. Without this a module that does not pin, say, maven-jar-plugin builds with the
			default of whatever Maven runs the build: a different version locally and in CI.
		-->
		<pluginManagement>
			<plugins>
				<plugin>
					<groupId>org.sonatype.central</groupId>
					<artifactId>central-publishing-maven-plugin</artifactId>
					<version>0.12.0</version>
				</plugin>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-compiler-plugin</artifactId>
					<version>3.16.0</version>
				</plugin>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-gpg-plugin</artifactId>
					<version>3.2.8</version>
				</plugin>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-jar-plugin</artifactId>
					<version>3.5.1</version>
				</plugin>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-javadoc-plugin</artifactId>
					<version>3.12.0</version>
				</plugin>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-resources-plugin</artifactId>
					<version>3.5.0</version>
				</plugin>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-source-plugin</artifactId>
					<version>3.4.0</version>
				</plugin>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-surefire-plugin</artifactId>
					<version>3.6.0</version>
				</plugin>
				<!--
					Bound by the clean and default lifecycles (clean, install, deploy) or invoked by prefix
					(mvn dependency:...) and configured nowhere else, so their versions came from whichever Maven ran the
					build: Maven 3.10.0 binds clean 3.5.0, install 3.2.0 and deploy 3.2.0 and manages no dependency plugin
					(dependency:... then takes the newest release); Maven 3.9 binds clean 3.2.0, install and deploy 3.1.x and
					manages dependency 3.7.0. Stated here so the build does not depend on the Maven that runs it, and so
					the maven-versions check of bernardladenthin/actions compares them across the repositories.
				-->
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-clean-plugin</artifactId>
					<version>3.5.0</version>
				</plugin>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-install-plugin</artifactId>
					<version>3.2.0</version>
				</plugin>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-deploy-plugin</artifactId>
					<version>3.2.0</version>
				</plugin>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-dependency-plugin</artifactId>
					<version>3.11.0</version>
				</plugin>
			</plugins>
		</pluginManagement>
		<plugins>
			<!--
				A CycloneDX software bill of materials for every module, attached as the `cyclonedx`
				classifier (json) so it is deployed to Central next to the jar, signed by maven-gpg
				like every other attached artifact. The natives directories carry their own
				jllama-sbom.json, written by llama/cmake/jllama-build-info.cmake from the native
				inputs (llama.cpp commit, patches, BoringSSL, toolkit), which Maven cannot see.
				TODO.md, delivery roadmap, item 1.
			-->
			<plugin>
				<groupId>org.cyclonedx</groupId>
				<artifactId>cyclonedx-maven-plugin</artifactId>
				<version>2.9.3</version>
				<executions>
					<execution>
						<id>sbom</id>
						<phase>package</phase>
						<goals>
							<goal>makeBom</goal>
						</goals>
					</execution>
				</executions>
				<configuration>
					<outputFormat>json</outputFormat>
					<includeTestScope>false</includeTestScope>
					<includeProvidedScope>false</includeProvidedScope>
				</configuration>
			</plugin>
		</plugins>
	</build>

	<profiles>
		<!--
			Reactor-wide release profile. Inherited by every module (llama, llama-langchain4j)
			AND applied to this parent pom itself, so a single `mvn -P release deploy` GPG-signs
			all artifacts (including the parent .pom, which Central requires) and routes the whole
			reactor through the Central Publishing plugin as one deployment. Activated only by the
			publish-snapshot / publish-release CI jobs. Their versions come from the pluginManagement
			above.
		-->
		<profile>
			<id>release</id>
			<build>
				<plugins>
					<plugin>
						<groupId>org.apache.maven.plugins</groupId>
						<artifactId>maven-gpg-plugin</artifactId>
						<executions>
							<execution>
								<id>sign-artifacts</id>
								<phase>verify</phase>
								<goals><goal>sign</goal></goals>
								<configuration>
									<keyname>${gpg.keyname}</keyname>
									<gpgArguments>
										<arg>--pinentry-mode</arg>
										<arg>loopback</arg>
									</gpgArguments>
								</configuration>
							</execution>
						</executions>
					</plugin>

					<plugin>
						<groupId>org.sonatype.central</groupId>
						<artifactId>central-publishing-maven-plugin</artifactId>
						<extensions>true</extensions>
						<configuration>
							<publishingServerId>central</publishingServerId>
							<autoPublish>true</autoPublish>
							<!-- uploaded: acknowledge transfer only; Central validates and publishes asynchronously -->
							<waitUntil>uploaded</waitUntil>
						</configuration>
					</plugin>
				</plugins>
			</build>
		</profile>
	</profiles>
</project>