Extract embedded POM from JAR during install/deploy instead of generating minimal stub

[Copilot]

• Update plugin reference to use current org.openidentityplatform.commons groupId/version (3.0.5-SNAPSHOT)
• Update compiler to Java 11; add staging.directory property
• Add maven-surefire-plugin configuration with staging directory system property
• Replace broken/dead URL examples with working Maven Central URLs (4 active examples)
• Add commented-out examples demonstrating each plugin feature (ZIP extraction, tar.gz extraction, force, custom POM, checksum, repack)
• Update JUnit from 3.8.1 to 4.13.2; replace obsolete runtime dependencies with commons-io and hamcrest-core
• Update AppTest.java to use JUnit 4 annotations with real assertions about staged artifacts
• Update App.java to use commons-io (replacing obsolete Google Translate API usage)
• Upgrade commons-io from 2.11.0 to 2.14.0 to fix XmlStreamReader DoS vulnerability (affects >= 2.0, < 2.14.0)
• Merge latest master into branch
• Fix indentation issues in maven-external-dependency-plugin-test/pom.xml (consistent 4-space indent throughout)

Original prompt

Issue

GitHub Issue: #44

Most JAR files built by Maven already contain their original pom.xml inside the JAR at META-INF/maven/<groupId>/<artifactId>/pom.xml. The maven-external-dependency-plugin should automatically extract and use this embedded POM instead of generating a bare-bones one with only GAV + packaging.

Current Behavior

In both InstallExternalDependencyMojo.java and DeployExternalDependencyMojo.java, the POM resolution logic is:

1. If pomFile is explicitly configured → use it
2. Otherwise → generate a minimal POM (only contains modelVersion, groupId, artifactId, version, packaging — no dependencies, no properties, no parent info)

This means dependency information, parent POM references, and other metadata from the original POM are lost.

Desired Behavior

Add an intermediate step that tries to extract the POM from inside the JAR before falling back to generating a minimal one:

1. If pomFile is explicitly configured → use it (unchanged)
2. NEW: If the staged artifact is a JAR and contains META-INF/maven/<groupId>/<artifactId>/pom.xml → extract it to a temp file and use it
3. Otherwise → generate a minimal POM (unchanged fallback)

Files to Modify

1. maven-external-dependency-plugin/maven-external-dependency-plugin/src/main/java/com/savage7/maven/plugin/dependency/AbstractExternalDependencyMojo.java

Add a new utility method extractPomFromJar(ArtifactItem artifactItem, File jarFile) that:

• Constructs the path META-INF/maven/<groupId>/<artifactId>/pom.xml
• Opens the JAR file using java.util.jar.JarFile
• Looks for the entry at that path
• If found, extracts it to a temporary file and returns it
• If not found, returns null
• Logs appropriate debug/info messages

2. maven-external-dependency-plugin/maven-external-dependency-plugin/src/main/java/com/savage7/maven/plugin/dependency/InstallExternalDependencyMojo.java

In the execute() method, in the else branch (lines ~187-203) where it currently generates a POM, change the logic to:

• First try extractPomFromJar(artifactItem, stagedArtifactFile)
• If a POM was extracted, use it as the ProjectArtifactMetadata
• If no POM was extracted AND generatePom is true, fall back to generatePomFile() as before

3. maven-external-dependency-plugin/maven-external-dependency-plugin/src/main/java/com/savage7/maven/plugin/dependency/DeployExternalDependencyMojo.java

Apply the same logic change as in InstallExternalDependencyMojo.java. In the else branch (lines ~144-155) where it currently generates a POM:

• First try extractPomFromJar(artifactItem, installedArtifactFile)
• If a POM was extracted, use it
• If not, fall back to generating one

4. maven-external-dependency-plugin/maven-external-dependency-plugin/src/main/java/com/savage7/maven/plugin/dependency/ArtifactItem.java

Add a new boolean configuration parameter extractPom (default true) with getter/setter, so users can disable the automatic extraction behavior per artifact if needed:

/**
 * Flag whether to attempt extracting POM from the JAR's META-INF directory.
 * 
 * @parameter default-value="true"
 */
private Boolean extractPom = true;

Important Notes

• The packaging check (!"pom".equals(...)) already exists and should remain — POM-type artifacts don't need POM extraction.
• The new extraction should only be attempted for jar packaging (or at minimum, file types that are ZIP-compatible).
• Ensure temporary files are properly cleaned up.
• Follow the existing code style (Javadoc-style annotations for Maven plugin parameters, braces on new lines, etc.).

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: проанализируй

Assistant:

I'll analyze this issue and the relevant codebase to understand what needs to be done.

Assistant: Вот подробный анализ issue #44 и связанного кода:

Анализ Issue #44: «Extract pom from jar when installing in maven repo»

Суть проблемы

Автор (@amichair) просит добавить в maven-external-dependency-plugin возможность автоматически извлекать POM-файл из JAR-архива (из META-INF/maven/<groupId>/<artifactId>/pom.xml), вместо того чтобы генерировать минимальный «пустой» POM.

Большинство JAR-файлов, собранных Maven, уже содержат свой оригинальный pom.xml внутри — с полным описанием зависимостей, properties и т.д. Сейчас плагин этот файл игнорирует.

---

Текущая логика (что нужно менять)

Ключевой файл: InstallExternalDependencyMojo.java

Текущая цепочка принятия решения о POM (строки 172–203):
...

This pull request was created from Copilot chat.

[vharseko]

@copilot merge from master

[Copilot]

@copilot merge from master

Done — merged origin/master into this branch in commit 730b347. The only change brought in was the .github/workflows/build.yml push-trigger branches filter (branches: ['sustaining/2.4.x','master']), no conflicts.

[maximthomas]

@copilot There are intendation issues in the pom file