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

	<parent>
		<groupId>dev.onvoid.webrtc</groupId>
		<artifactId>webrtc-java-parent</artifactId>
		<version>0.19.0</version>
	</parent>

	<artifactId>webrtc-java-media</artifactId>

	<name>webrtc-java-media</name>
	<description>
		Media extension for webrtc-java. Reads and decodes media files and network streams with
		FFmpeg and feeds them into a peer connection.
	</description>

	<properties>
		<!-- The FFmpeg release the third-party/ffmpeg submodule is pinned to. -->
		<ffmpeg.version>8.1</ffmpeg.version>
		<!-- Where the compiled FFmpeg libraries are installed and looked for. A
		     build reuses an existing install instead of building again, the way
		     the WebRTC checkout is reused. -->
		<ffmpeg.install.dir>${user.home}/ffmpeg/${platform.classifier}</ffmpeg.install.dir>
		<cmake.build.type>Release</cmake.build.type>
		<!-- The phases the native build runs in, so that it can be turned off
		     with -DskipNativeBuild. The test-natives lane does that: there the
		     natives come from the job that cross compiled them, and building
		     them again on a machine whose only job is to run them would prove
		     nothing. These are the goals' own default phases. -->
		<cmake.generate.phase>process-sources</cmake.generate.phase>
		<cmake.compile.phase>compile</cmake.compile.phase>
		<!-- Generator options, set per platform below. This module links only
		     against FFmpeg's C ABI and the JVM, never against WebRTC's C++
		     ABI, so it needs no special toolchain or standard library. -->
		<cmake.options />
		<cmake.config />
		<!-- Linux and Windows-on-ARM build through webrtc-jni's toolchain
		     files, so that both native libraries of a platform are built for
		     the same target, against the same sysroot, and so end up with the
		     same glibc floor. On Linux that also means compiling with
		     -nostdinc++ and taking the C++ standard library from where
		     webrtc-jni takes it, which is what webrtc.install.dir is for
		     below. A native macOS build needs no file; the Intel build made on
		     Apple Silicon takes webrtc-jni's cross one. -->
		<cmake.toolchain.file />
		<jni.toolchain.dir>${project.basedir}/../webrtc-jni/src/main/cpp/toolchain</jni.toolchain.dir>
		<!-- Where webrtc-jni installed WebRTC, and with it the libc++ that its
		     toolchain files expect. Same default as webrtc-jni's own. -->
		<webrtc.install.dir>${user.home}/webrtc/build</webrtc.install.dir>
	</properties>

	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
			</plugin>

			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-surefire-plugin</artifactId>
				<configuration>
					<!-- Unlike webrtc, which resolves its natives as a jar
					     built by webrtc-jni, this module builds its own. At
					     test time they are not packaged yet, so the staging
					     directory the CMake build collects them into goes on
					     the class path instead: NativeLoader looks the
					     libraries up as class path resources, and a directory
					     serves them as well as a jar does. -->
					<additionalClasspathElements>
						<additionalClasspathElement>${project.build.directory}/natives</additionalClasspathElement>
					</additionalClasspathElements>
					<!-- The release the libraries on that path have to be,
					     so that a test catches an install left over from an
					     earlier one. Not named ffmpeg.version itself: CI reads
					     the version out of this file by that element name, and
					     has to find it exactly once. -->
					<systemPropertyVariables>
						<test.ffmpeg.version>${ffmpeg.version}</test.ffmpeg.version>
					</systemPropertyVariables>
				</configuration>
			</plugin>

			<!-- Builds FFmpeg and the native media library for this platform. -->
			<plugin>
				<groupId>com.googlecode.cmake-maven-project</groupId>
				<artifactId>cmake-maven-plugin</artifactId>
				<version>3.31.5-b1</version>
				<executions>
					<execution>
						<id>cmake-generate</id>
						<phase>${cmake.generate.phase}</phase>
						<goals>
							<goal>generate</goal>
						</goals>
						<configuration>
							<sourcePath>src/main/cpp</sourcePath>
							<targetPath>${project.build.directory}/${platform.classifier}</targetPath>
							<options>
								<option>
									"${cmake.options}"
								</option>
								<option>
									-DMEDIA_TOOLCHAIN_FILE=${cmake.toolchain.file}
								</option>
								<option>
									-DWEBRTC_INSTALL_DIR=${webrtc.install.dir}
								</option>
								<option>
									-DFFMPEG_INSTALL_DIR=${ffmpeg.install.dir}
								</option>
								<option>
									-DFFMPEG_VERSION=${ffmpeg.version}
								</option>
								<option>
									-DCMAKE_BUILD_TYPE=${cmake.build.type}
								</option>
								<option>
									-DOUTPUT_NAME_SUFFIX=${platform.classifier}
								</option>
							</options>
						</configuration>
					</execution>
					<execution>
						<id>cmake-compile</id>
						<phase>${cmake.compile.phase}</phase>
						<goals>
							<goal>compile</goal>
						</goals>
						<configuration>
							<config>${cmake.config}</config>
							<projectDirectory>${project.build.directory}/${platform.classifier}</projectDirectory>
						</configuration>
					</execution>
				</executions>
			</plugin>

			<!-- The native library and the FFmpeg shared libraries go into a
			     jar of their own, one per platform, exactly as webrtc-java
			     ships its natives. The main jar stays platform independent. -->
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-jar-plugin</artifactId>
				<executions>
					<execution>
						<id>natives-jar</id>
						<phase>package</phase>
						<goals>
							<goal>jar</goal>
						</goals>
						<configuration>
							<classifier>${platform.classifier}</classifier>
							<classesDirectory>${project.build.directory}/natives</classesDirectory>
							<archive>
								<manifestEntries>
									<FFmpeg-Version>${ffmpeg.version}</FFmpeg-Version>
									<FFmpeg-License>LGPL-2.1-or-later</FFmpeg-License>
								</manifestEntries>
							</archive>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>

	<!--
		The natives of this module are not a dependency of it. They are built
		and attached by this same module, so a dependency on them could not be
		resolved on the first build of a clean machine: nothing has produced
		them yet. webrtc-java can depend on its own classifier artifact only
		because webrtc-jni, an earlier module, is what builds it.

		Anything using this module therefore asks for the natives itself, with
		a second dependency carrying the platform classifier. The tests here
		need no such thing: Surefire is given the directory the CMake build
		collects them into.
	-->
	<dependencies>
		<dependency>
			<groupId>dev.onvoid.webrtc</groupId>
			<artifactId>webrtc-java</artifactId>
			<version>${project.version}</version>
		</dependency>
	</dependencies>

	<profiles>
		<!-- Runs the tests against natives built elsewhere, as the
		     test-natives lane does after unpacking them into target/natives,
		     which is where Surefire is already told to look. -->
		<profile>
			<id>skip-native-build</id>
			<activation>
				<property>
					<name>skipNativeBuild</name>
				</property>
			</activation>
			<properties>
				<cmake.generate.phase>none</cmake.generate.phase>
				<cmake.compile.phase>none</cmake.compile.phase>
			</properties>
		</profile>

		<!-- Release: attach the natives jars of all supported platforms, which
		     the release workflow has collected into "natives.dir" from the
		     per-platform build jobs, as webrtc does with its own. Nothing is
		     built natively then, and no natives jar is made for the host: the
		     one downloaded for it is attached instead.

		     Run with: mvn deploy -pl .,webrtc,webrtc-java-media -Prelease -Dnatives.dir=/abs/path -->
		<profile>
			<id>attach-natives-all</id>
			<activation>
				<property>
					<name>natives.dir</name>
				</property>
			</activation>
			<properties>
				<cmake.generate.phase>none</cmake.generate.phase>
				<cmake.compile.phase>none</cmake.compile.phase>
			</properties>
			<build>
				<plugins>
					<plugin>
						<groupId>org.apache.maven.plugins</groupId>
						<artifactId>maven-jar-plugin</artifactId>
						<executions>
							<execution>
								<id>natives-jar</id>
								<phase>none</phase>
							</execution>
						</executions>
					</plugin>
					<plugin>
						<groupId>org.codehaus.mojo</groupId>
						<artifactId>build-helper-maven-plugin</artifactId>
						<executions>
							<execution>
								<id>attach-natives</id>
								<phase>package</phase>
								<goals>
									<goal>attach-artifact</goal>
								</goals>
								<configuration>
									<artifacts>
										<artifact>
											<file>${natives.dir}/${project.artifactId}-${project.version}-windows-x86_64.jar</file>
											<type>jar</type>
											<classifier>windows-x86_64</classifier>
										</artifact>
										<artifact>
											<file>${natives.dir}/${project.artifactId}-${project.version}-windows-aarch64.jar</file>
											<type>jar</type>
											<classifier>windows-aarch64</classifier>
										</artifact>
										<artifact>
											<file>${natives.dir}/${project.artifactId}-${project.version}-linux-x86_64.jar</file>
											<type>jar</type>
											<classifier>linux-x86_64</classifier>
										</artifact>
										<artifact>
											<file>${natives.dir}/${project.artifactId}-${project.version}-linux-aarch64.jar</file>
											<type>jar</type>
											<classifier>linux-aarch64</classifier>
										</artifact>
										<artifact>
											<file>${natives.dir}/${project.artifactId}-${project.version}-linux-aarch32.jar</file>
											<type>jar</type>
											<classifier>linux-aarch32</classifier>
										</artifact>
										<artifact>
											<file>${natives.dir}/${project.artifactId}-${project.version}-macos-x86_64.jar</file>
											<type>jar</type>
											<classifier>macos-x86_64</classifier>
										</artifact>
										<artifact>
											<file>${natives.dir}/${project.artifactId}-${project.version}-macos-aarch64.jar</file>
											<type>jar</type>
											<classifier>macos-aarch64</classifier>
										</artifact>
									</artifacts>
								</configuration>
							</execution>
						</executions>
					</plugin>
				</plugins>
			</build>
		</profile>

		<!-- The platform profiles mirror webrtc-jni's, by name and by the
		     toolchain file each one selects, so that both native libraries of
		     a given classifier are built for the same target the same way. -->
		<profile>
			<id>linux-x86_64</id>
			<activation>
				<os>
					<family>linux</family>
					<arch>amd64</arch>
				</os>
			</activation>
			<properties>
				<cmake.toolchain.file>${jni.toolchain.dir}/x86_64-linux-clang.cmake</cmake.toolchain.file>
			</properties>
		</profile>
		<profile>
			<id>linux-aarch32</id>
			<activation>
				<os>
					<family>linux</family>
					<arch>aarch32</arch>
				</os>
			</activation>
			<properties>
				<cmake.toolchain.file>${jni.toolchain.dir}/aarch32-linux-clang.cmake</cmake.toolchain.file>
			</properties>
		</profile>
		<profile>
			<id>linux-aarch64</id>
			<activation>
				<os>
					<family>linux</family>
					<arch>aarch64</arch>
				</os>
			</activation>
			<properties>
				<cmake.toolchain.file>${jni.toolchain.dir}/aarch64-linux-clang.cmake</cmake.toolchain.file>
			</properties>
		</profile>
		<profile>
			<id>macos-aarch64</id>
			<activation>
				<os>
					<family>mac</family>
					<arch>aarch64</arch>
				</os>
			</activation>
			<!-- Builds for the architecture Maven itself is running as, so it
			     needs no toolchain file. -->
		</profile>
		<!-- The Intel build, made on an Apple Silicon host. -->
		<profile>
			<id>macos-cross-x86_64</id>
			<properties>
				<cmake.toolchain.file>${jni.toolchain.dir}/x86_64-macos-cross.cmake</cmake.toolchain.file>
			</properties>
		</profile>

		<!-- Reruns the tests under -Xcheck:jni, which turns a JNI reference
		     mistake into a hard error instead of a crash somewhere later. Not
		     part of the default build: see the note in the root CLAUDE.md. -->
		<profile>
			<id>jni-check</id>
			<build>
				<plugins>
					<plugin>
						<groupId>org.apache.maven.plugins</groupId>
						<artifactId>maven-surefire-plugin</artifactId>
						<configuration>
							<!-- -Xcheck:jni writes straight to the process's
							     native stdout, which corrupts Surefire's
							     default pipe based fork protocol on that same
							     stream, so the fork talks over a socket. -->
							<forkNode implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory" />
							<argLine>-Xcheck:jni</argLine>
						</configuration>
					</plugin>
				</plugins>
			</build>
		</profile>

		<profile>
			<id>windows-x86_64</id>
			<activation>
				<os>
					<family>windows</family>
					<arch>amd64</arch>
				</os>
			</activation>
			<properties>
				<cmake.options>-Ax64</cmake.options>
				<cmake.config>${cmake.build.type}</cmake.config>
			</properties>
		</profile>
		<profile>
			<id>windows-aarch64</id>
			<properties>
				<cmake.options>-AARM64</cmake.options>
				<cmake.config>${cmake.build.type}</cmake.config>
				<cmake.toolchain.file>${jni.toolchain.dir}/aarch64-windows-clang.cmake</cmake.toolchain.file>
			</properties>
		</profile>
	</profiles>

</project>
