AFAIK, this is due to the fact that the skin uses itself, which is a good thing to show the effective result for people wanting to use it, but it costs this little problem: the most recent version is the version actually built, not what is in local repo (at least when working with SNAPSHOT)
so in this case, "mvn -Preporting package site" will do the job Regards, Hervé Le lundi 9 décembre 2013 20:47:20 Michael-O a écrit : > Hi, > > during release preps of 1.3.1 I am constantly failing to build the with > Maven 3.1.1. I do "mvn -Preporting site" and it dies with > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on > project maven-fluido-skin: Error during site generation: > D:\Projekte\maven-fluido-skin\target\classes (Zugriff verweigert) -> > [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site > (default-site) on project maven-fluido-skin: Error during site generation > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:2 > 16) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:1 > 53) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:1 > 45) at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Life > cycleModuleBuilder.java:84) at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Life > cycleModuleBuilder.java:59) at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(Lif > ecycleStarter.java:183) at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarte > r.java:161) at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) at > org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57 > ) at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl > .java:43) at java.lang.reflect.Method.invoke(Method.java:606) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.ja > va:289) at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher. > java:415) at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error during > site generation > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:147) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPl > uginManager.java:106) at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:2 > 08) ... 19 more > Caused by: java.io.FileNotFoundException: > D:\Projekte\maven-fluido-skin\target\classes (Zugriff verweigert) > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.<init>(ZipFile.java:215) > at java.util.zip.ZipFile.<init>(ZipFile.java:145) > at java.util.zip.ZipFile.<init>(ZipFile.java:159) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.getZipFile(DefaultSi > teRenderer.java:684) at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.createContextForSkin > (DefaultSiteRenderer.java:643) at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingC > ontext(AbstractSiteRenderingMojo.java:346) at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154) at > org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138) ... 21 > more > > It simply means that it actually tried to read the JAR file of the skin > but received the classes directory from target. I have traced this one > down to org.apache.maven.artifact.resolver.DefaultArtifactResolver (3.0) > but cannot proceed with debugging because the debug symbols do not match > to the source code. > > Has anyone a clue why the system tries to resolve from target/classes > instead of my local repository? > > I highly assume that this is some Sonatype => Eclipse Aether issue. > > Insights welcome, > > Michael > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
