Failed to init Classpath for jar file C:\apache-maven-3.9.6\boot\plexus-classworlds.license during compilation
I am getting the following error during build with Maven 3.9.6 and Java 21.
The effective POM part for the compiler plugin is below the exception
trace. Is this a known issue?
[INFO] --- compiler:3.12.1:compile (default-compile) @ apmservices.artemis
---
[INFO] Recompiling the module because of changed source code.
[INFO] Compiling with eclipse [debug:lines,vars,source parameters release
21] to target\classes
*Failed to init Classpath for jar file
C:\apache-maven-3.9.6\boot\plexus-classworlds.license*
java.util.zip.ZipException: zip END header not found
at java.base/java.util.zip.ZipFile$Source.findEND(ZipFile.java:1649)
at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1657)
at java.base/java.util.zip.ZipFile$Source.(ZipFile.java:1495)
at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1458)
at
java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:724)
at java.base/java.util.zip.ZipFile.(ZipFile.java:251)
at java.base/java.util.zip.ZipFile.(ZipFile.java:180)
at java.base/java.util.zip.ZipFile.(ZipFile.java:194)
at
org.eclipse.jdt.internal.compiler.batch.ClasspathJar.initialize(ClasspathJar.java:204)
at
org.eclipse.jdt.internal.compiler.batch.ClasspathMultiReleaseJar.initialize(ClasspathMultiReleaseJar.java:38)
at
org.eclipse.jdt.internal.compiler.batch.FileSystem.(FileSystem.java:233)
at
org.eclipse.jdt.internal.compiler.batch.Main.getLibraryAccess(Main.java:3480)
at
org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4726)
at
org.eclipse.jdt.internal.compiler.tool.EclipseCompilerImpl.call(EclipseCompilerImpl.java:101)
at
org.eclipse.jdt.internal.compiler.tool.EclipseCompiler$1.call(EclipseCompiler.java:196)
at
org.codehaus.plexus.compiler.eclipse.EclipseJavaCompiler.performCompile(EclipseJavaCompiler.java:307)
at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1188)
at
org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:212)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:126)
at
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:328)
at
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:316)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:174)
at
org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:75)
at
org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:162)
at
org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:105)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:53)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:261)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:173)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:101)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:906)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:283)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:206)
at
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:283)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:226)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:407)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:348)
at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
Effective POM section:
maven-compiler-plugin
3.12.1
default-compile
compile
compile
21
21
21
eclipse
true
true
lines,vars,source
-properties
${settings.localRepository}/com/ca/apm/binaries/jdt.core.prefs/1.0.2/jdt.core.prefs-1.0.2.prefs
true
com.ca.apm.binaries
jdt.core.prefs
1.0.2
prefs
compile
org.codehaus.plexus
plexus-compiler-eclipse
2.14.2
compile
21
21
Re: How to suppress meta tags 'generator', 'date' in Doxia Site Renderer?
Sorry for replying slowly due to intercontinental travel. What sebb said is just one issue. The other, even more obviuous one is that a timestamp is a tinmestamp is a timestamp and hence therefore changes each time I generate the site. -- Alexander Kriegisch https://scrum-master.de sebb schrieb am 28.02.2024 15:01 (GMT +01:00): > On Wed, 28 Feb 2024 at 13:40, Michael Osipov wrote: >> >> On 2024/02/22 06:59:01 Alexander Kriegisch wrote: >> > Hello Maven community. >> > >> > When generating Maven sites, I like to keep the diffs to previous >> > version to the absolute minimum before committing changes to a published >> > site. My commits should only contain content changes. Therefore, I >> > already use this in my site.xml: >> > >> > >> > >> > true >> > >> > >> > >> > Unfortunately, I found no way to suppress these generated tags on each >> > single page: >> > >> > > /> >> > >> > >> > They constitute about 90% of my commit diffs, making it look like all >> > pages have changed in the commit log, even though maybe I just fixed a >> > typo on a single page. How can I customise that behaviour? >> >> I do not fully understand which problem you have. As long as you stay on the >> same version of all affected components there should be no diff, but only >> your >> content change. Can you elaborate? What do you exactly change? > > Suppose you release version 1.2.2 of a project using Doxia 1.11.0 > Later you would like to release version 1.2.3, by then Doxia 1.11.1 is out. > > As part of checking the release, you would like to check that the > Javadoc changes properly reflect the code changes. > However the Doxia version change generates tons of spurious output. > >> The source of that metadata is stable from: >> * >> https://github.com/apache/maven-fluido-skin/blob/7cb683f5505badcb7ecac9569c8445ae435377d8/src/main/resources/META-INF/maven/site.vm#L20-L43 >> * >> https://maven.apache.org/doxia/doxia-sitetools/doxia-site-renderer/index.html >> >> M >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: a question about the Maven Resolver Ant Tasks uber JAR
So how should this issue be resolved? Should the exclusion be removed? > On Feb 28, 2024, at 9:33 PM, Thorsten Heit wrote: > > Hi, > >> For reasons that I may no longer believe, I tried to make a JAR that >> included the Maven Resolver Ant Tasks uber JAR plus some extra stuff. >> I figured I could do that by resolving the Maven Resolver Ant Tasks and >> including all those artifacts in my JAR. >> But that did not work. >> The resulting JAR fails because of a class not found: >> org/apache/commons/logging/LogFactory [called from http AbstractVerifier]. >> What seems odd is that the POM for maven-resolver-transport-http *explicitly >> excludes commons-logging*. >> The stated explanation is that jcl-over-slf4j is used instead. >> But obviously, there is some need for commons-logging, and the MRAT uber JAR >> includes commons-logging. >> Is commons-logging added to the MRAT uber JAR as a special case? > > As long as *jcl-over-slf4j* itself is included, that explains the > presence of commons-logging stuff: > > > % jar tf > ~/.m2/repository/org/slf4j/jcl-over-slf4j/2.0.9/jcl-over-slf4j-2.0.9.jar > | sort > META-INF/ > (...) > org/ > org/apache/ > org/apache/commons/ > org/apache/commons/logging/ > org/apache/commons/logging/Log.class > org/apache/commons/logging/LogConfigurationException.class > org/apache/commons/logging/LogFactory.class > org/apache/commons/logging/impl/ > org/apache/commons/logging/impl/NoOpLog.class > org/apache/commons/logging/impl/SLF4JLocationAwareLog.class > org/apache/commons/logging/impl/SLF4JLog.class > org/apache/commons/logging/impl/SLF4JLogFactory.class > org/apache/commons/logging/impl/SimpleLog.class > > > Regards > > Thorsten > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: a question about the Maven Resolver Ant Tasks uber JAR
Re-reading your "I tried to make a JAR that included the Maven Resolver Ant Tasks uber JAR plus some extra stuff"... The Maven Resolver Ant Tasks uber JAR contains _relocated_ classes (see POM). Hence, using this uber JAR to create another uber JAR is not recommended (or make sure there are no shared dependencies). You'd be better if you used non-uber JAR dependencies of Ant Tasks and other stuff and create uber jar out of those instead. T On Fri, Mar 1, 2024 at 4:55 PM Alan Snyder wrote: > So how should this issue be resolved? > > Should the exclusion be removed? > > > On Feb 28, 2024, at 9:33 PM, Thorsten Heit wrote: > > > > Hi, > > > >> For reasons that I may no longer believe, I tried to make a JAR that > included the Maven Resolver Ant Tasks uber JAR plus some extra stuff. > >> I figured I could do that by resolving the Maven Resolver Ant Tasks and > including all those artifacts in my JAR. > >> But that did not work. > >> The resulting JAR fails because of a class not found: > org/apache/commons/logging/LogFactory [called from http AbstractVerifier]. > >> What seems odd is that the POM for maven-resolver-transport-http > *explicitly excludes commons-logging*. > >> The stated explanation is that jcl-over-slf4j is used instead. > >> But obviously, there is some need for commons-logging, and the MRAT > uber JAR includes commons-logging. > >> Is commons-logging added to the MRAT uber JAR as a special case? > > > > As long as *jcl-over-slf4j* itself is included, that explains the > > presence of commons-logging stuff: > > > > > > % jar tf > > ~/.m2/repository/org/slf4j/jcl-over-slf4j/2.0.9/jcl-over-slf4j-2.0.9.jar > > | sort > > META-INF/ > > (...) > > org/ > > org/apache/ > > org/apache/commons/ > > org/apache/commons/logging/ > > org/apache/commons/logging/Log.class > > org/apache/commons/logging/LogConfigurationException.class > > org/apache/commons/logging/LogFactory.class > > org/apache/commons/logging/impl/ > > org/apache/commons/logging/impl/NoOpLog.class > > org/apache/commons/logging/impl/SLF4JLocationAwareLog.class > > org/apache/commons/logging/impl/SLF4JLog.class > > org/apache/commons/logging/impl/SLF4JLogFactory.class > > org/apache/commons/logging/impl/SimpleLog.class > > > > > > Regards > > > > Thorsten > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Failed to init Classpath for jar file C:\apache-maven-3.9.6\boot\plexus-classworlds.license during compilation
Howdy,
Can you post debug output how the compiler plugin is invoked?
Also, looks related:
https://github.com/eclipse-jdt/eclipse.jdt.core/issues/1578
T
On Fri, Mar 1, 2024 at 10:37 AM Václav Haisman wrote:
> I am getting the following error during build with Maven 3.9.6 and Java 21.
> The effective POM part for the compiler plugin is below the exception
> trace. Is this a known issue?
>
> [INFO] --- compiler:3.12.1:compile (default-compile) @ apmservices.artemis
> ---
> [INFO] Recompiling the module because of changed source code.
> [INFO] Compiling with eclipse [debug:lines,vars,source parameters release
> 21] to target\classes
> *Failed to init Classpath for jar file
> C:\apache-maven-3.9.6\boot\plexus-classworlds.license*
> java.util.zip.ZipException: zip END header not found
> at java.base/java.util.zip.ZipFile$Source.findEND(ZipFile.java:1649)
> at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1657)
> at java.base/java.util.zip.ZipFile$Source.(ZipFile.java:1495)
> at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1458)
> at
> java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:724)
> at java.base/java.util.zip.ZipFile.(ZipFile.java:251)
> at java.base/java.util.zip.ZipFile.(ZipFile.java:180)
> at java.base/java.util.zip.ZipFile.(ZipFile.java:194)
> at
>
> org.eclipse.jdt.internal.compiler.batch.ClasspathJar.initialize(ClasspathJar.java:204)
> at
>
> org.eclipse.jdt.internal.compiler.batch.ClasspathMultiReleaseJar.initialize(ClasspathMultiReleaseJar.java:38)
> at
>
> org.eclipse.jdt.internal.compiler.batch.FileSystem.(FileSystem.java:233)
> at
>
> org.eclipse.jdt.internal.compiler.batch.Main.getLibraryAccess(Main.java:3480)
> at
>
> org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4726)
> at
>
> org.eclipse.jdt.internal.compiler.tool.EclipseCompilerImpl.call(EclipseCompilerImpl.java:101)
> at
>
> org.eclipse.jdt.internal.compiler.tool.EclipseCompiler$1.call(EclipseCompiler.java:196)
> at
>
> org.codehaus.plexus.compiler.eclipse.EclipseJavaCompiler.performCompile(EclipseJavaCompiler.java:307)
> at
>
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1188)
> at
>
> org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:212)
> at
>
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:126)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:328)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:316)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:174)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:75)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:162)
> at
>
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
>
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159)
> at
>
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:105)
> at
>
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
> at
>
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:53)
> at
>
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:206)
> at
>
> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at
>
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:283)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:226)
> at
>
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:407)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:348)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
>
> Effective POM section:
>
>
> maven-compiler-plugin
> 3.12.1
>
>
> default-compile
> compile
>
> compile
>
>
> 21
> 21
> 21
> eclipse
> true
> true
> lines,vars,source
>
> -properties
>
>
> ${
Re: How to suppress meta tags 'generator', 'date' in Doxia Site Renderer?
On 2024/02/28 14:01:42 sebb wrote: > On Wed, 28 Feb 2024 at 13:40, Michael Osipov wrote: > > > > On 2024/02/22 06:59:01 Alexander Kriegisch wrote: > > > Hello Maven community. > > > > > > When generating Maven sites, I like to keep the diffs to previous > > > version to the absolute minimum before committing changes to a published > > > site. My commits should only contain content changes. Therefore, I > > > already use this in my site.xml: > > > > > > > > > > > > true > > > > > > > > > > > > Unfortunately, I found no way to suppress these generated tags on each > > > single page: > > > > > > > > > > > > > > > They constitute about 90% of my commit diffs, making it look like all > > > pages have changed in the commit log, even though maybe I just fixed a > > > typo on a single page. How can I customise that behaviour? > > > > I do not fully understand which problem you have. As long as you stay on > > the same version of all affected components there should be no diff, but > > only your content change. Can you elaborate? What do you exactly change? > > Suppose you release version 1.2.2 of a project using Doxia 1.11.0 > Later you would like to release version 1.2.3, by then Doxia 1.11.1 is out. > > As part of checking the release, you would like to check that the > Javadoc changes properly reflect the code changes. > However the Doxia version change generates tons of spurious output. True, that is what I wanted to hear. I have/had the same problem during dev/testing. Raise an issue with the skin, please. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to suppress meta tags 'generator', 'date' in Doxia Site Renderer?
On 2024/03/01 15:34:42 Alexander Kriegisch wrote: > Sorry for replying slowly due to intercontinental travel. > > What sebb said is just one issue. The other, even more obviuous one is > that a timestamp is a tinmestamp is a timestamp and hence therefore > changes each time I generate the site. Which exact? The generation date can be skipped, there are no other skin-supplied dates or timestamps embedded. M - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to suppress meta tags 'generator', 'date' in Doxia Site Renderer?
Michael, did you read my original message? Everything is described quite precisely and concisely there. > I already use this in my site.xml: > > > > true > > > > Unfortunately, I found no way to suppress these generated tags on each > single page: > > > I.e., that setting does *not* stop timestamp meta tags from being generated, only timestamps visible on generated pages. This is why the subject of this thread is: "How to suppress meta tags 'generator', 'date' in Doxia Site Renderer?" I was asking, because I was hoping that somebody could tell me if there were any existing options to suppress those meta tags. If you know one, your insights are most welcome. Please, just tell me what I missed and which setting to tweak to suppress the tag(s). Regards -- Alexander Kriegisch https://scrum-master.de Michael Osipov schrieb am 01.03.2024 um 21:37: > On 2024/03/01 15:34:42 Alexander Kriegisch wrote: >> Sorry for replying slowly due to intercontinental travel. >> >> What sebb said is just one issue. The other, even more obviuous one is >> that a timestamp is a tinmestamp is a timestamp and hence therefore >> changes each time I generate the site. > > Which exact? The generation date can be skipped, there are no other > skin-supplied dates or timestamps embedded. > > M > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
