gnodet commented on PR #13490:
URL: https://github.com/apache/maven/pull/13490#issuecomment-6214844740
Thanks @rmannibucau for the final pair of questions.
**1. Preserve the jar name in the distro for backward compat?**
Yes, strongly agreed. The assembled distribution currently ships
`boot/maven-classworlds-<version>.jar` (and `mvn`/`mvn.cmd` glob on that name).
Any custom wrapper script, CI provisioning script, or tooling that greps or
globs `plexus-classworlds-*.jar` in `boot/` will silently break.
The assembly plugin supports `<outputFileNameMapping>` on a
`<dependencySet>` to rename the artifact in the assembled directory
independently of its Maven coordinates. We can keep the file named
`plexus-classworlds-<version>.jar` in `boot/` without touching the
groupId/artifactId:
```xml
<dependencySet>
<useProjectArtifact>false</useProjectArtifact>
<outputDirectory>boot</outputDirectory>
<includes>
<include>org.apache.maven:maven-classworlds</include>
</includes>
<outputFileNameMapping>plexus-classworlds-${artifact.version}.jar</outputFileNameMapping>
</dependencySet>
```
`mvn`/`mvn.cmd` then keep their existing `plexus-classworlds-*.jar` glob and
need no change either. Will apply this before merging.
**2. Drop the `src/test/test-data/` binary jars and generate them
programmatically?**
The jars (`a.jar`, `b.jar`, `component0-1.0.jar`, `deadlock.jar`, …) are
compiled class fixtures that have been binary files in plexus-classworlds since
its initial commit — they contain simple stub classes (`a.A`, `a.Aa`,
`deadlock.A`/`B`/`C`/`D`, etc.) that the classloading tests load across realm
boundaries.
Generating them at test time would require either: (a) a separate Maven
sub-module that compiles them and produces JARs before the main module's tests
run, or (b) an in-test bytecode generation approach (e.g. ASM). Both are
significantly more complex than static fixtures and would themselves need
sources tracked in git — just Java source files instead of class files.
My preference is to leave them as binary test fixtures in this PR (it
faithfully copies the plexus-classworlds approach) and track the replacement as
a follow-up if the project wants it. Keeping the scope of this internalization
PR minimal makes review easier.
Does that work for you, or would you prefer we tackle the jar generation in
this PR?
_Claude Code on behalf of Guillaume Nodet_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
