Repository navigation
Conversation
Replace MavenArchiveConfiguration/MavenArchiver with local ArchiveConfiguration and ManifestBuilder classes. ManifestBuilder inlines the manifest generation logic from MavenArchiver.getManifest(), using: - java.util.jar.Manifest directly (no plexus types) - org.apache.maven.api.services.Interpolator for classpath layout interpolation (replaces plexus-interpolation) - Inlined BuildHelper.discoverJavaRelease() (pure Maven API) ArchiveConfiguration replaces MavenArchiveConfiguration with inner ManifestConfig and ManifestSection classes matching the same plugin parameter XML structure.
- Fix stale @link: ManifestConfig#isAddBuildEnvironmentEntries() does not exist (bare field, no getter); use field reference instead - Add null/empty name guard in manifest section loop to prevent NPE at Manifest.getEntries().put(null, attrs) when <name> is missing - Add ManifestBuilderTest covering: Build-Jdk-Spec presence/absence, extra entry precedence and sanitization, null/empty section name guard, Manifest-Version, and Created-By defaults
…sleading test, add classpath tests - ManifestBuilder: move null/empty name guard before building Attributes object in manifest section loop (fail-fast, no needless allocation) - ManifestBuilderTest: rename buildJdkSpecPresentByDefault to buildJdkSpecPresentWhenFieldDefaultIsTrue with a comment clarifying this tests the field-level default, not production behaviour (which AbstractJarMojo always overrides to false via addBuildEnvironmentEntries) - ManifestBuilderTest: add classpath unit tests via SessionWithServices stub that vends inline DependencyResolver and Interpolator stubs: * classpathSimpleLayout — simple layout with useUniqueVersions=true * classpathRepositoryLayout — repository layout (groupId path) * classpathWithPrefix — classpathPrefix prepended to each entry
The maven-archiver dependency has been removed in this PR. Update all
site documentation that still linked to or described Maven Archiver:
- usage.md.vm: drop stale archiver link and ${mavenArchiverVersion}
variable; update last-line executable JAR link to local example
- index.md: rename section to 'Archive Configuration'; replace Maven
Archiver prose with ManifestBuilder/ArchiveConfiguration description
- faq.md: rewrite archive-parameter answer in terms of ArchiveConfiguration
- manifest-customization.md.vm: replace three Maven Archiver links with
local ManifestBuilder description and plugin-info reference
- site.xml: remove two Maven Archiver sidebar entries
('Creating an Executable JAR File' and 'Using Your Own Manifest File')
Built-By and Build-Jdk-Spec are only included when addBuildEnvironmentEntries is true (default: false). Only Created-By (and Java-Version when discoverable) are present by default.
…rchiver-dep # Conflicts: # pom.xml
…lified build() method
The jar tool adds Manifest-Version automatically; no need to set it in ManifestBuilder. Created-By is handled by ToolExecutor (removed for non-reproducible builds, set to a JDK-independent value for reproducible builds); ManifestBuilder setting it is redundant and the setCreatedBy() method is removed along with the pluginVersion field it used. Also make ManifestSection.manifestEntries final and rename test method to reflect the eager ManifestConfig initialization.
…x redundant calls, update doc and stale comment
…ute loss java.util.jar.Manifest.write() silently drops all main attributes when Manifest-Version is absent from the manifest. This caused a regression introduced in commit c2a3401: ManifestBuilder.buildManifest() creates a new Manifest but never sets Manifest-Version, so the temp manifest file written by MetadataFiles.addManifest() → manifest.write() contained only \r\n (2 bytes), causing the jar tool to read an empty manifest. Fix: set Manifest-Version: 1.0 unconditionally in buildManifest(), as MavenArchiver.getManifest() always did. Also add a regression test that verifies Manifest-Version is present in the built manifest and that manifest.write() produces non-empty output.
Rename single-letter and abbreviated local variable names to their full, descriptive counterparts as requested by @elharo: - m -> manifest (Manifest local in buildManifest) - org -> organization (Organization local in addSpecificationEntries and addImplementationEntries) - p -> plugin (Plugin local in getPlugin) - mgmt -> pluginManagement (PluginManagement local in getPlugin) - conf -> configuration (XmlNode local in getPluginParameter) Also add missing java.nio.file.Files import and replace the fully-qualified java.nio.file.Files.isRegularFile() call with the short form.
…ference from ArchiveConfiguration
… buildJdkSpecDefaultEntry flag The flag was always set to the same value as addBuildEnvironmentEntries by AbstractJarMojo. Moving Build-Jdk-Spec directly into addBuildEnvironmentEntries() removes the indirection and simplifies the code. Tests updated accordingly.
… CLASS_PATH, drop redundant toString()
Maven XML/Plexus binding can inject null for an empty <classpathPrefix/> element. StringBuilder.append(null) silently appends the literal string "null", corrupting classpath entries. Add an explicit null-and-empty check before appending.
The null check alone is sufficient. Appending an empty string is a no-op, so the !prefix.isEmpty() check is unnecessary. Suggested by @desruisseaux.
…ustomization Since maven-archiver is removed as a dependency, all configuration options must be documented here rather than delegating to the maven-archiver shared docs. Adds: - Full table of <archive> top-level options (compress, addMavenDescriptor, forced, manifestFile, manifest, manifestEntries, manifestSections) - Full table of <archive><manifest> options with types, defaults, and descriptions - Classpath layout expression reference (artifact.* interpolation expressions) - Worked examples: executable JAR, Class-Path generation, specification/implementation entries, manifest sections, and using an existing manifest file Addresses: apache#618 (review)
added 8 commits
October 18, 2026 08:50
…ion.md.vm
The .vm file is processed by the Velocity template engine during
site generation. Literal ${artifact.*} references in the documentation
tables and layout examples were being interpreted as Velocity variable
references, causing a ParseErrorException at line 61.
Escape all literal ${...} expressions with \$ so Velocity treats them
as plain text, while leaving the intentional ${project.version}
substitutions untouched.
…ier expression
- manifestFile type was documented as File; the actual field is Path
- pomPropertiesFile (Path) was missing from the archive options table
- Normalize ${artifact.dashClassifier} to ${dashClassifier?} in the
expressions table to match the layout-equivalent examples below it
…plate
The ${artifact.*} and ${dashClassifier?} expressions in
manifest-customization.md.vm were written as \${...} which caused a
Velocity ParseErrorException during site generation: Velocity attempted
to evaluate ${artifact.*} as a reference (invalid Velocity syntax).
Replace all occurrences with ${esc.d}{...} which is the established
pattern already used in this file (see line with project.url) and renders
as ${...} in the generated HTML output.
…rmalization, specificationVersion, packageName/addExtensions Addresses issues raised in Copilot review: 1. addBuildEnvironmentEntries: restore Build-Tool (Apache Maven <version>), Build-Os (os.name, version, arch), and the full Build-Jdk format (java.version + vendor in parentheses), matching maven-archiver behaviour. 2. classpathPrefix normalization: replace backslashes with forward slashes and add a trailing '/' automatically when absent, preventing '<classpathPrefix>lib</classpathPrefix>' from producing 'liblib-a-1.0.jar' instead of 'lib/lib-a-1.0.jar'. 3. specificationVersion(): avoid producing an invalid trailing-dot string (e.g. '1.' for version '1.foo'); only append a dot if the next character is also a digit. 4. ArchiveConfiguration.ManifestConfig: add 'packageName' field (generates the Package manifest attribute) and 'addExtensions' field (accepted for compatibility with maven-archiver; no-op in this implementation). Documentation and unit tests updated accordingly.
CLASSPATH_LAYOUT_TYPE_REPOSITORY and CLASSPATH_LAYOUT_TYPE_CUSTOM were only used internally in resolveLayout() and were not more readable than the literal strings. Inline them as per @elharo's suggestion. CLASSPATH_LAYOUT_TYPE_SIMPLE is kept as it serves as the default value in ArchiveConfiguration.
…ed ManifestBuilder Replace the inlined ManifestBuilder and ArchiveConfiguration classes with maven-archiver 4.0.0-beta-7-SNAPSHOT (MavenArchiver + MavenArchiveConfiguration). This keeps the JDK jar tool approach from pr-618 while delegating manifest generation back to the shared maven-archiver library.
gnodet
force-pushed
the
feat/use-maven-archiver
branch
from
October 19, 2026 09:16
05a4270 to
f99ea18
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Migrates maven-jar-plugin away from
plexus-archiverto the JDK built-injartool for archive creation, delegating manifest generation tomaven-archiver(without plexus dependency).This supersedes the approach in #618 where
ManifestBuilderwas inlined in the plugin. Following Hervé's feedback, manifest generation now lives in maven-archiver as shared code.Changes
Kept from #618
ToolExecutor: JDKjartool invocation via@argfile, staging directory, reproducible builds supportFileCollector: file collection fromtarget/classes/MetadataFiles: pom.xml/pom.properties temp file generationArchive,DirectoryRole,ExcludedFiles,PomDerivation,TimestampCheck: unchangedReplaced vs #618
ManifestBuilder→ deleted, replaced byMavenArchiver.getManifest(session, project, archive)frommaven-archiver:4.0.0-beta-7-SNAPSHOTArchiveConfiguration→ deleted, replaced byMavenArchiveConfigurationfrom maven-archiverpom.xml
maven-archiver:4.0.0-beta-7-SNAPSHOTplexus-archiver(was removed in Remove maven-archiver and plexus-archiver dependencies #618 already)Depends on
apache/maven-archiver#422 — which removes
plexus-archiverfrom maven-archiver itself and changesgetManifest()return type tojava.util.jar.Manifest.