[jira] [Updated] (MSOURCES-137) Artifacts generated by maven-source-plugin are not reproducible because they depend on the umask
[ https://issues.apache.org/jira/browse/MSOURCES-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated MSOURCES-137: - Description: It appears that inside the archive created by maven-source-plugin, the permissions of {{META-INF/maven/\*/\*/pom.properties}} depend on the current umask. Steps to reproduce: {code:java} $ umask 022 $ mvn clean install $ umask 002 $ mvn clean verify artifact:compare {code} This can be used on any project attaching a source jar (e.g. [https://github.com/apache/ws-axiom/]). Example diffoscope output: {code:java} --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar │┄ Archive contents identical but files differ, possibly due to different compression levels. Falling back to binary comparison. ├── zipinfo {} │ @@ -14,9 +14,9 @@ │ -rw-r--r-- 2.0 unx 170 b- defN 22-Mar-13 11:17 META-INF/NOTICE │ -rw-r--r-- 2.0 unx 1365 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/FactoryMethod.java │ -rw-r--r-- 2.0 unx 1101 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Inject.java │ -rw-r--r-- 2.0 unx 1095 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Mixin.java │ -rw-r--r-- 2.0 unx 1100 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Singleton.java │ -rw-r--r-- 2.0 unx 1136 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/WeavablePackage.java │ -rw-r--r-- 2.0 unx 1411 b- defN 22-Mar-13 11:17 META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.xml │ --rw-r--r-- 2.0 unx 95 b- defN 22-Mar-13 11:17 META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties │ +-rw-rw-r-- 2.0 unx 95 b- defN 22-Mar-13 11:17 META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties │ 20 files, 19157 bytes uncompressed, 8089 bytes compressed: 57.8% │ --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar ├── +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar │ @@ -676,15 +676,15 @@ │ 2a30: a481 b020 4d45 5441 . ..META │ 2a40: 2d49 4e46 2f6d 6176 656e 2f6f 7267 2e61 -INF/maven/org.a │ 2a50: 7061 6368 652e 7773 2e63 6f6d 6d6f 6e73 pache.ws.commons │ 2a60: 2e61 7869 6f6d 2f61 7869 6f6d 2d77 6561 .axiom/axiom-wea │ 2a70: 7665 722d 616e 6e6f 7461 7469 6f6e 732f ver-annotations/ │ 2a80: 706f 6d2e 786d 6c50 4b01 0214 0314 pom.xmlPK... │ 2a90: 0808 0022 5a6d 54b9 68bb 2558 005f ..."ZmT.h.%X..._ │ -2aa0: 0052 00a4 ...R │ +2aa0: 0052 00b4 ...R │ 2ab0: 81e8 2300 004d 4554 412d 494e 462f 6d61 ..#..META-INF/ma │ 2ac0: 7665 6e2f 6f72 672e 6170 6163 6865 2e77 ven/org.apache.w │ 2ad0: 732e 636f 6d6d 6f6e 732e 6178 696f 6d2f s.commons.axiom/ │ 2ae0: 6178 696f 6d2d 7765 6176 6572 2d61 6e6e axiom-weaver-ann │ 2af0: 6f74 6174 696f 6e73 2f70 6f6d 2e70 726f otations/pom.pro │ 2b00: 7065 7274 6965 7350 4b05 0600 0014 pertiesPK... │ 2b10: 0014 0057 0600 00b0 2400 00 ...W$ {code} Note that although maven-jar-plugin adds the same {{pom.properties}} file to the archive, it isn't affected by this problem. I discovered this while trying to check the reproducibility of Apache Axiom builds in a Github Codespace, where file permissions are set in a peculiar way; see [https://github.com/orgs/community/discussions/26026]. was: It appears that inside the archive created by maven-source-plugin, the permissions of {{META-INF/maven/*/*/pom.properties}} depend on the current umask. Steps to reproduce: {code:java} $ umask 022 $ mvn clean install $ umask 002 $ mvn clean verify artifact:compare {code} This can be used on any project attaching a source jar (e.g. [https://github.com/apache/ws-axiom/]). Example diffoscope output: {code:java} --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar │┄ Archive contents identical but files differ, possibly due to different compression levels. Falling back to binary comparison. ├── zipinfo {} │ @@ -14,9 +14,9 @@ │ -rw-r--r-- 2.0 unx 170 b- defN 22-Mar-13 11:17 META-INF/NOTICE │ -rw-r--r-- 2.0 unx 1365 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/FactoryMethod.java │ -rw-r--r-- 2.0 unx 1101 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Inject.java │ -rw-r--r-- 2.0 unx 1095 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Mixin.java │ -rw-r--r-- 2.0 unx 1100 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Singleton.java │ -rw-r--r-- 2.0 unx 1136 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annota
[jira] [Updated] (MSOURCES-137) Artifacts generated by maven-source-plugin are not reproducible because they depend on the umask
[ https://issues.apache.org/jira/browse/MSOURCES-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated MSOURCES-137: - Description: It appears that inside the archive created by maven-source-plugin, the permissions of {{META-INF/maven/*/*/pom.properties}} depend on the current umask. Steps to reproduce: {code:java} $ umask 022 $ mvn clean install $ umask 002 $ mvn clean verify artifact:compare {code} This can be used on any project attaching a source jar (e.g. [https://github.com/apache/ws-axiom/]). Example diffoscope output: {code:java} --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar │┄ Archive contents identical but files differ, possibly due to different compression levels. Falling back to binary comparison. ├── zipinfo {} │ @@ -14,9 +14,9 @@ │ -rw-r--r-- 2.0 unx 170 b- defN 22-Mar-13 11:17 META-INF/NOTICE │ -rw-r--r-- 2.0 unx 1365 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/FactoryMethod.java │ -rw-r--r-- 2.0 unx 1101 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Inject.java │ -rw-r--r-- 2.0 unx 1095 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Mixin.java │ -rw-r--r-- 2.0 unx 1100 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Singleton.java │ -rw-r--r-- 2.0 unx 1136 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/WeavablePackage.java │ -rw-r--r-- 2.0 unx 1411 b- defN 22-Mar-13 11:17 META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.xml │ --rw-r--r-- 2.0 unx 95 b- defN 22-Mar-13 11:17 META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties │ +-rw-rw-r-- 2.0 unx 95 b- defN 22-Mar-13 11:17 META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties │ 20 files, 19157 bytes uncompressed, 8089 bytes compressed: 57.8% │ --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar ├── +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar │ @@ -676,15 +676,15 @@ │ 2a30: a481 b020 4d45 5441 . ..META │ 2a40: 2d49 4e46 2f6d 6176 656e 2f6f 7267 2e61 -INF/maven/org.a │ 2a50: 7061 6368 652e 7773 2e63 6f6d 6d6f 6e73 pache.ws.commons │ 2a60: 2e61 7869 6f6d 2f61 7869 6f6d 2d77 6561 .axiom/axiom-wea │ 2a70: 7665 722d 616e 6e6f 7461 7469 6f6e 732f ver-annotations/ │ 2a80: 706f 6d2e 786d 6c50 4b01 0214 0314 pom.xmlPK... │ 2a90: 0808 0022 5a6d 54b9 68bb 2558 005f ..."ZmT.h.%X..._ │ -2aa0: 0052 00a4 ...R │ +2aa0: 0052 00b4 ...R │ 2ab0: 81e8 2300 004d 4554 412d 494e 462f 6d61 ..#..META-INF/ma │ 2ac0: 7665 6e2f 6f72 672e 6170 6163 6865 2e77 ven/org.apache.w │ 2ad0: 732e 636f 6d6d 6f6e 732e 6178 696f 6d2f s.commons.axiom/ │ 2ae0: 6178 696f 6d2d 7765 6176 6572 2d61 6e6e axiom-weaver-ann │ 2af0: 6f74 6174 696f 6e73 2f70 6f6d 2e70 726f otations/pom.pro │ 2b00: 7065 7274 6965 7350 4b05 0600 0014 pertiesPK... │ 2b10: 0014 0057 0600 00b0 2400 00 ...W$ {code} Note that although maven-jar-plugin adds the same {{pom.properties}} file to the archive, it isn't affected by this problem. I discovered this while trying to check the reproducibility of Apache Axiom builds in a Github Codespace, where file permissions are set in a peculiar way; see [https://github.com/orgs/community/discussions/26026]. was: It appears that inside the archive created by maven-source-plugin, the permissions of {{META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties}} depend on the current umask. Steps to reproduce: {code} $ umask 022 $ mvn clean install $ umask 002 $ mvn clean verify artifact:compare {code} This can be used on any project attaching a source jar (e.g. https://github.com/apache/ws-axiom/). Example diffoscope output: {code} --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar │┄ Archive contents identical but files differ, possibly due to different compression levels. Falling back to binary comparison. ├── zipinfo {} │ @@ -14,9 +14,9 @@ │ -rw-r--r-- 2.0 unx 170 b- defN 22-Mar-13 11:17 META-INF/NOTICE │ -rw-r--r-- 2.0 unx 1365 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/FactoryMethod.java │ -rw-r--r-- 2.0 unx 1101 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Inject.java │ -rw-r--r-- 2.0 unx 1095 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Mixin.java │ -rw-r--r-- 2.0 unx 1100 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Singleton.java │ -rw-r--r-- 2.0 unx 1136 b- defN 22-Mar-1
[jira] [Created] (MSOURCES-137) Artifacts generated by maven-source-plugin are not reproducible because they depend on the umask
Andreas Veithen created MSOURCES-137: Summary: Artifacts generated by maven-source-plugin are not reproducible because they depend on the umask Key: MSOURCES-137 URL: https://issues.apache.org/jira/browse/MSOURCES-137 Project: Maven Source Plugin Issue Type: Bug Affects Versions: 3.3.0 Reporter: Andreas Veithen It appears that inside the archive created by maven-source-plugin, the permissions of {{META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties}} depend on the current umask. Steps to reproduce: {code} $ umask 022 $ mvn clean install $ umask 002 $ mvn clean verify artifact:compare {code} This can be used on any project attaching a source jar (e.g. https://github.com/apache/ws-axiom/). Example diffoscope output: {code} --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar │┄ Archive contents identical but files differ, possibly due to different compression levels. Falling back to binary comparison. ├── zipinfo {} │ @@ -14,9 +14,9 @@ │ -rw-r--r-- 2.0 unx 170 b- defN 22-Mar-13 11:17 META-INF/NOTICE │ -rw-r--r-- 2.0 unx 1365 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/FactoryMethod.java │ -rw-r--r-- 2.0 unx 1101 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Inject.java │ -rw-r--r-- 2.0 unx 1095 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Mixin.java │ -rw-r--r-- 2.0 unx 1100 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/Singleton.java │ -rw-r--r-- 2.0 unx 1136 b- defN 22-Mar-13 11:17 org/apache/axiom/weaver/annotation/WeavablePackage.java │ -rw-r--r-- 2.0 unx 1411 b- defN 22-Mar-13 11:17 META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.xml │ --rw-r--r-- 2.0 unx 95 b- defN 22-Mar-13 11:17 META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties │ +-rw-rw-r-- 2.0 unx 95 b- defN 22-Mar-13 11:17 META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties │ 20 files, 19157 bytes uncompressed, 8089 bytes compressed: 57.8% │ --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar ├── +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar │ @@ -676,15 +676,15 @@ │ 2a30: a481 b020 4d45 5441 . ..META │ 2a40: 2d49 4e46 2f6d 6176 656e 2f6f 7267 2e61 -INF/maven/org.a │ 2a50: 7061 6368 652e 7773 2e63 6f6d 6d6f 6e73 pache.ws.commons │ 2a60: 2e61 7869 6f6d 2f61 7869 6f6d 2d77 6561 .axiom/axiom-wea │ 2a70: 7665 722d 616e 6e6f 7461 7469 6f6e 732f ver-annotations/ │ 2a80: 706f 6d2e 786d 6c50 4b01 0214 0314 pom.xmlPK... │ 2a90: 0808 0022 5a6d 54b9 68bb 2558 005f ..."ZmT.h.%X..._ │ -2aa0: 0052 00a4 ...R │ +2aa0: 0052 00b4 ...R │ 2ab0: 81e8 2300 004d 4554 412d 494e 462f 6d61 ..#..META-INF/ma │ 2ac0: 7665 6e2f 6f72 672e 6170 6163 6865 2e77 ven/org.apache.w │ 2ad0: 732e 636f 6d6d 6f6e 732e 6178 696f 6d2f s.commons.axiom/ │ 2ae0: 6178 696f 6d2d 7765 6176 6572 2d61 6e6e axiom-weaver-ann │ 2af0: 6f74 6174 696f 6e73 2f70 6f6d 2e70 726f otations/pom.pro │ 2b00: 7065 7274 6965 7350 4b05 0600 0014 pertiesPK... │ 2b10: 0014 0057 0600 00b0 2400 00 ...W$ {code} Note that although maven-jar-plugin adds the same {{pom.properties}} file to the archive, it isn't affected by this problem. I discovered this while trying to check the reproducibility of Apache Axiom builds in a Github Codespace, where file permissions are set in a peculiar way; see https://github.com/orgs/community/discussions/26026. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-384) Cannot invoke "String.equals(Object)" because the return value of "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null
[ https://issues.apache.org/jira/browse/MPLUGIN-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17461888#comment-17461888 ] Andreas Veithen commented on MPLUGIN-384: - I ran into the same problem. I noticed that after the first deployment, the {{maven-metadata.xml}} file in the repository contains a {{plugin}} element without a {{prefix}}. Subsequent deployments then fail with the exception shown in the description. > Cannot invoke "String.equals(Object)" because the return value of > "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null > > > Key: MPLUGIN-384 > URL: https://issues.apache.org/jira/browse/MPLUGIN-384 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Affects Versions: 3.6.2 > Environment: Windows 10 64-bit, Java 8 and 17, maven 3.8.1 >Reporter: Bob Marinier >Priority: Major > > Version 3.6.1 of maven-plugin-plugin worked fine, but since updating to > version 3.6.2, I get an NPE (tested with Java 8 and Java 17). I believe the > error in both Java 8 and Java 17 is the same, but Java 17 gives a better > message (see below). Even though it's the nexus-staging-maven-plugin that is > complaining, the message implies that the maven-plugin-plugin is somehow > failing to extract the prefix from the plugin. Going back to > maven-plugin-plugin version 3.6.1 fixes the issue. > {{[ERROR] Failed to execute goal > org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy > (injected-nexus-deploy) on project my-maven-plugin: Failed to update metadata > my.group.id/maven-metadata.xml: Cannot invoke "String.equals(Object)" because > the return value of > "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null -> > [Help 1]}} > {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.8:deploy > (injected-nexus-deploy) on project my-maven-plugin: Failed to update metadata > my.group.id/maven-metadata.xml: Cannot invoke "String.equals(Object)" because > the return value of > "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null}} > {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215)}} > {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156)}} > {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148)}} > {{ at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117)}} > {{ at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81)}} > {{ at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56)}} > {{ at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128)}} > {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)}} > {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)}} > {{ at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)}} > {{ at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)}} > {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)}} > {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)}} > {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native > Method)}} > {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:77)}} > {{ at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:43)}} > {{ at java.lang.reflect.Method.invoke (Method.java:568)}} > {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282)}} > {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225)}} > {{ at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406)}} > {{ at org.codehaus.plexus.classworlds.launcher.Launcher.main > (Launcher.java:347)}} > {{Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to update > metadata my.group.id/maven-metadata.xml: Cannot invoke > "String.equals(Object)" because the return value of > "org.apache.maven.artifact.repository.metadata.Plugin.getPrefix()" is null}} > {{ at org.sonatype.nexus.maven.staging.deploy.DeployMojo.execute > (DeployMojo.java:216)}} > {{ at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:137)}} > {{ at org.apache.maven.lifecycle.internal.MojoExecuto
[jira] [Commented] (MNG-6506) Mojos are unable to load package annotations on Java >= 9
[ https://issues.apache.org/jira/browse/MNG-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801039#comment-16801039 ] Andreas Veithen commented on MNG-6506: -- Oh, and actually there is already a branch with the necessary change: https://github.com/apache/maven/tree/MNG-6543. Just needs to be merged into master. > Mojos are unable to load package annotations on Java >= 9 > - > > Key: MNG-6506 > URL: https://issues.apache.org/jira/browse/MNG-6506 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.6.0 >Reporter: Andreas Veithen >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: up-for-grabs > Fix For: 3.6.1 > > Time Spent: 10m > Remaining Estimate: 0h > > On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from > within a Mojo always return {{null}} (unless the {{package-info}} class has > been loaded by some other means before). > The reason appears to be an incompatibility between Java 9 and Plexus > Classworlds: > * Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the > {{package-info}} class. > * The {{findClass}} implementation in {{ClassRealm}} always throws > {{ClassNotFoundException}}: > https://github.com/codehaus-plexus/plexus-classworlds/blob/master/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275. > This in particular affects plugins that interact with the JAXB API because it > relies on package annotations. > A workaround is to preload the required {{package-info}} classes using > {{loadClass}}; see e.g. http://svn.apache.org/viewvc?rev=1845026&view=rev. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6506) Mojos are unable to load package annotations on Java >= 9
[ https://issues.apache.org/jira/browse/MNG-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801028#comment-16801028 ] Andreas Veithen commented on MNG-6506: -- MNG-6543 is about updating plexus-classworlds. No need to create another issue I think. > Mojos are unable to load package annotations on Java >= 9 > - > > Key: MNG-6506 > URL: https://issues.apache.org/jira/browse/MNG-6506 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.6.0 >Reporter: Andreas Veithen >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: up-for-grabs > Fix For: 3.6.1 > > Time Spent: 10m > Remaining Estimate: 0h > > On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from > within a Mojo always return {{null}} (unless the {{package-info}} class has > been loaded by some other means before). > The reason appears to be an incompatibility between Java 9 and Plexus > Classworlds: > * Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the > {{package-info}} class. > * The {{findClass}} implementation in {{ClassRealm}} always throws > {{ClassNotFoundException}}: > https://github.com/codehaus-plexus/plexus-classworlds/blob/master/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275. > This in particular affects plugins that interact with the JAXB API because it > relies on package annotations. > A workaround is to preload the required {{package-info}} classes using > {{loadClass}}; see e.g. http://svn.apache.org/viewvc?rev=1845026&view=rev. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6506) Mojos are unable to load package annotations on Java >= 9
[ https://issues.apache.org/jira/browse/MNG-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800053#comment-16800053 ] Andreas Veithen commented on MNG-6506: -- Done: https://github.com/apache/maven-integration-testing/pull/43 > Mojos are unable to load package annotations on Java >= 9 > - > > Key: MNG-6506 > URL: https://issues.apache.org/jira/browse/MNG-6506 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.6.0 >Reporter: Andreas Veithen >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: up-for-grabs > Fix For: 3.6.1 > > Time Spent: 10m > Remaining Estimate: 0h > > On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from > within a Mojo always return {{null}} (unless the {{package-info}} class has > been loaded by some other means before). > The reason appears to be an incompatibility between Java 9 and Plexus > Classworlds: > * Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the > {{package-info}} class. > * The {{findClass}} implementation in {{ClassRealm}} always throws > {{ClassNotFoundException}}: > https://github.com/codehaus-plexus/plexus-classworlds/blob/master/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275. > This in particular affects plugins that interact with the JAXB API because it > relies on package annotations. > A workaround is to preload the required {{package-info}} classes using > {{loadClass}}; see e.g. http://svn.apache.org/viewvc?rev=1845026&view=rev. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6506) Mojos are unable to load package annotations on Java >= 9
[ https://issues.apache.org/jira/browse/MNG-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1688#comment-1688 ] Andreas Veithen commented on MNG-6506: -- I'll give it a try. > Mojos are unable to load package annotations on Java >= 9 > - > > Key: MNG-6506 > URL: https://issues.apache.org/jira/browse/MNG-6506 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.6.0 >Reporter: Andreas Veithen >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: up-for-grabs > Fix For: 3.6.1 > > > On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from > within a Mojo always return {{null}} (unless the {{package-info}} class has > been loaded by some other means before). > The reason appears to be an incompatibility between Java 9 and Plexus > Classworlds: > * Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the > {{package-info}} class. > * The {{findClass}} implementation in {{ClassRealm}} always throws > {{ClassNotFoundException}}: > https://github.com/codehaus-plexus/plexus-classworlds/blob/master/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275. > This in particular affects plugins that interact with the JAXB API because it > relies on package annotations. > A workaround is to preload the required {{package-info}} classes using > {{loadClass}}; see e.g. http://svn.apache.org/viewvc?rev=1845026&view=rev. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6506) Mojos are unable to load package annotations on Java >= 9
[ https://issues.apache.org/jira/browse/MNG-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674425#comment-16674425 ] Andreas Veithen commented on MNG-6506: -- A minimal test case can be found here: [https://github.com/veithen/MNG-6506]. The project builds successfully on Java 8 and fails on Java 9. > Mojos are unable to load package annotations on Java >= 9 > - > > Key: MNG-6506 > URL: https://issues.apache.org/jira/browse/MNG-6506 > Project: Maven > Issue Type: Bug > Components: Class Loading >Affects Versions: 3.6.0 >Reporter: Andreas Veithen >Priority: Major > > On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from > within a Mojo always return {{null}} (unless the {{package-info}} class has > been loaded by some other means before). > The reason appears to be an incompatibility between Java 9 and Plexus > Classworlds: > * Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the > {{package-info}} class. > * The {{findClass}} implementation in {{ClassRealm}} always throws > {{ClassNotFoundException}}: > https://github.com/sonatype/plexus-classworlds/blob/plexus-classworlds-2.5.2/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275. > This in particular affects plugins that interact with the JAXB API because it > relies on package annotations. A workaround is to preload the required > {{package-info}} classes using {{loadClass}}; see e.g. > http://svn.apache.org/viewvc?rev=1845026&view=rev. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6506) Mojos are unable to load package annotations on Java >= 9
Andreas Veithen created MNG-6506: Summary: Mojos are unable to load package annotations on Java >= 9 Key: MNG-6506 URL: https://issues.apache.org/jira/browse/MNG-6506 Project: Maven Issue Type: Bug Components: Class Loading Affects Versions: 3.6.0 Reporter: Andreas Veithen On Java 9 and above, calls to {{java.lang.Package.getAnnotation(Class)}} from within a Mojo always return {{null}} (unless the {{package-info}} class has been loaded by some other means before). The reason appears to be an incompatibility between Java 9 and Plexus Classworlds: * Java 9 ultimately calls {{findClass}} (instead of {{loadClass}}) to get the {{package-info}} class. * The {{findClass}} implementation in {{ClassRealm}} always throws {{ClassNotFoundException}}: https://github.com/sonatype/plexus-classworlds/blob/plexus-classworlds-2.5.2/src/main/java/org/codehaus/plexus/classworlds/realm/ClassRealm.java#L275. This in particular affects plugins that interact with the JAXB API because it relies on package annotations. A workaround is to preload the required {{package-info}} classes using {{loadClass}}; see e.g. http://svn.apache.org/viewvc?rev=1845026&view=rev. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (DOXIA-373) Macro snippet with file option in a multi-pom project
[ https://issues.apache.org/jira/browse/DOXIA-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14431956#comment-14431956 ] Andreas Veithen edited comment on DOXIA-373 at 11/26/15 3:18 PM: - A workaround for this issue is to use (assuming that the file is a Velocity template, i.e. has suffix .apt.vm instead of .apt): {noformat} %{snippet|id=deployment|file=${project.basedir}/src/test/resources/client-config.wsdd} {noformat} was (Author: veithen): A workaround for this issue is to use (assuming that the file is a Velocity templete, i.e. has suffix .apt.vm instead of .apt): %{snippet|id=deployment|file=${project.basedir}/src/test/resources/client-config.wsdd} > Macro snippet with file option in a multi-pom project > - > > Key: DOXIA-373 > URL: https://issues.apache.org/jira/browse/DOXIA-373 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt > Environment: Window XP >Reporter: T. Montembault > > The project is a multi pom project. In the main pom project, I declare the > other pom like this : > {code:xml} > > ../moduleA > ../moduleB >... > > {code} > To avoid duplicate code,I use the macro snippet in my documentation in > modules A, B and Main. For convenient, the following syntax : > {noformat} %{snippet|id=myid|file=src/main/java/mypackage/File.java} > {noformat}. > When I build the site from each module A or B, all work fine. But when the > site was generated from the main module, the snippet seem not work : All the > pages who include a snippet's macros in A or B are not generated. I obtain > the same problem if i do a simple site or a site:stage > > The maven site work fine work include pictures and schemas of local > documentation (in A et B). I try to use > the velocity macro and transform {{MyFile.apt}} to {{MyFile.apt.vm}} like > these : > {noformat} > MyFile.apt.vm > %{snippet|id=myid|file=${basedir}/src/main/java/mypackage/File.java}. > {noformat} > It's fail too. > I use maven 2.1.0 > Sorry for my poor english -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (DOXIA-492) Add support for doxia macros in markdown documents.
[ https://issues.apache.org/jira/browse/DOXIA-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated DOXIA-492: -- Attachment: maven-site-plugin-integration-test.patch Attached patch to add an integration test to maven-site-plugin. > Add support for doxia macros in markdown documents. > --- > > Key: DOXIA-492 > URL: https://issues.apache.org/jira/browse/DOXIA-492 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Markdown >Affects Versions: 1.4 >Reporter: Juergen Kellerer > Attachments: maven-site-plugin-integration-test.patch, screen.png > > > It would be nice if doxia macros could be supported also inside markdown > documents (similar to APT). > Existing macros (especially snippet) is very useful, however with the power > of maven there's the ability to register own macros for a build process which > enables reuse of resources and improves dryness in general. > A syntax which may work could be the following: > * Block Level > {noformat} >#`??MACRO_NAME MACRO_ARGS` > {noformat} > * Inline > {noformat} > `??MACRO_NAME MACRO_ARGS` > {noformat} > Reference: > http://hackage.haskell.org/packages/archive/yesod-markdown/0.0/doc/html/Yesod-Markdown-Macros.html > E.g. using "Texts" it works just from the Editor: > !screen.png! > When macros are not interpreted, they fallback to a code block, thus it's > easy to edit these sort of documents with one of the existing nice markdown > editors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIA-492) Add support for doxia macros in markdown documents.
[ https://issues.apache.org/jira/browse/DOXIA-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15020925#comment-15020925 ] Andreas Veithen commented on DOXIA-492: --- Your change sets secondParsing=true, but then macros are not executed. With secondParsing=false I get the expected result. > Add support for doxia macros in markdown documents. > --- > > Key: DOXIA-492 > URL: https://issues.apache.org/jira/browse/DOXIA-492 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Markdown >Affects Versions: 1.4 >Reporter: Juergen Kellerer > Attachments: screen.png > > > It would be nice if doxia macros could be supported also inside markdown > documents (similar to APT). > Existing macros (especially snippet) is very useful, however with the power > of maven there's the ability to register own macros for a build process which > enables reuse of resources and improves dryness in general. > A syntax which may work could be the following: > * Block Level > {noformat} >#`??MACRO_NAME MACRO_ARGS` > {noformat} > * Inline > {noformat} > `??MACRO_NAME MACRO_ARGS` > {noformat} > Reference: > http://hackage.haskell.org/packages/archive/yesod-markdown/0.0/doc/html/Yesod-Markdown-Macros.html > E.g. using "Texts" it works just from the Editor: > !screen.png! > When macros are not interpreted, they fallback to a code block, thus it's > easy to edit these sort of documents with one of the existing nice markdown > editors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DOXIA-492) Add support for doxia macros in markdown documents.
[ https://issues.apache.org/jira/browse/DOXIA-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15020697#comment-15020697 ] Andreas Veithen commented on DOXIA-492: --- I tried this, but got the following exception: {noformat} java.lang.NullPointerException at org.apache.maven.doxia.parser.AbstractParser.executeMacro(AbstractParser.java:116) at org.apache.maven.doxia.module.xhtml.XhtmlParser.processMacro(XhtmlParser.java:269) at org.apache.maven.doxia.module.xhtml.XhtmlParser.handleComment(XhtmlParser.java:234) at org.apache.maven.doxia.parser.AbstractXmlParser.parseXml(AbstractXmlParser.java:263) at org.apache.maven.doxia.parser.AbstractXmlParser.parse(AbstractXmlParser.java:145) at org.apache.maven.doxia.parser.XhtmlBaseParser.parse(XhtmlBaseParser.java:96) at org.apache.maven.doxia.module.xhtml.XhtmlParser.parse(XhtmlParser.java:357) at org.apache.maven.doxia.module.markdown.MarkdownParser.parse(MarkdownParser.java:109) at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:411) at org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:51) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:324) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:132) at org.apache.maven.plugins.site.render.SiteMojo.renderDoxiaDocuments(SiteMojo.java:262) at org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:172) at org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:141) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) ... 21 more {noformat} Looks like a problem with the injection of MacroManager. > Add support for doxia macros in markdown documents. > --- > > Key: DOXIA-492 > URL: https://issues.apache.org/jira/browse/DOXIA-492 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Markdown >Affects Versions: 1.4 >Reporter: Juergen Kellerer > Attachments: screen.png > > > It would be nice if doxia macros could be supported also inside markdown > documents (similar to APT). > Existing macros (especially snippet) is very useful, however with the power > of maven there's the ability to register own macros for a build process which > enables reuse of resources and improves dryness in general. > A syntax which may work could be the following: > * Block Level > {noformat} >#`??MACRO_NAME MACRO_ARGS` > {noformat} > * Inline > {noformat} > `??MACRO_NAME MACRO_ARGS` > {noformat} > Reference: > http://hackage.haskell.org/packages/archive/yesod-markdown/0.0/doc/html/Yesod-Markdown-Macros.html > E.g. using "Texts" it works just from the Editor: > !screen.png! > When macros are not interpreted, they fallback to a code block, thus it's > easy to edit these sort of documents with one of the existing nice markdown > editors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MANTRUN-90) Allow antrun to fork ant process in a different jvm
[ https://jira.codehaus.org/browse/MANTRUN-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342277#comment-342277 ] Andreas Veithen commented on MANTRUN-90: There is another interesting use case for this feature. Assume that you have a Maven project that builds some Ant tasks. You may then want to use maven-antrun-plugin to execute some integration tests for these tasks. If antrun allowed to fork the ant process (and to pass command line arguments to the forked process), you could then easily instrument the VM to measure the code coverage of these tests (e.g. with Jacoco). > Allow antrun to fork ant process in a different jvm > --- > > Key: MANTRUN-90 > URL: https://jira.codehaus.org/browse/MANTRUN-90 > Project: Maven Antrun Plugin > Issue Type: Improvement >Affects Versions: 1.1 > Environment: Windows, Maven 2.0.9 >Reporter: Clement Denis > Attachments: antrun-conf.xml > > > I'm using an ant task (provided by Weblogic) that generates classes and > compiles them with the tools.jar from the JDK. > This task doesn't allow to specify neither source or target version for the > compiler. > So, the generated classes are compiled against the currently running JVM, > using its rt.jar and the tools.jar provided in plugin dependencies (or placed > in the lib/ext directory of the jvm). > As Maven is executed in a 1.5 JVM (1.5 is needed for some modules in my > project), these classes are compiled in 1.5. > The server where I want to deploy them is running on a 1.4 JVM, so the > generated classes can't run in this server. > I couldn't find a way to tell antrun to compile my classes using a different > java version. > I tried the following workarounds : > - change the tools.jar dependency to point to a 1.4 version => as the > compiler uses the rt.jar from the currently running 1.5 JVM, the class file > version doesn't match (version 49.0, expecting 48.0) > - add a dependency to a 1.4 rt.jar => it doesn't change anything, as the > rt.jar should be specified in the boot classpath. > The possible solutions would be : > - allow antrun to fork ant process to a different jvm > - allow antrun to override the boot classpath -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"
[ https://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305380#comment-305380 ] Andreas Veithen commented on MDEP-259: -- @Ian: Sorry, I did that several months ago and I don't remember the details. > copy-dependencies fails with "Error copying artifact from .../target/classes > to .../classes" > > > Key: MDEP-259 > URL: https://jira.codehaus.org/browse/MDEP-259 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy, copy-dependencies >Affects Versions: 2.0, 2.1 > Environment: Maven 2.0.9 > maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616) >Reporter: Andreas Veithen > Attachments: patch.txt, test-project.zip > > > Scenario: > * dependency:copy-dependencies is used to copy a dependency artifact that is > part of the same multi-module build. > * The compile phase is executed, but not the package phase. > An example of this scenario is using maven-eclipse-plugin to import a Maven > project with generated test (re)sources. In this case, one would execute "mvn > generate-test-resources eclipse:eclipse" to make sure that the generated > (re)sources are imported into the workspace (by default, maven-eclipse-plugin > executes generate-sources and generate-resources, but not > generate-test-sources and generate-test-resources). > Result: The build fails with the following error: > {noformat}[INFO] [dependency:copy-dependencies {execution: default}] > [INFO] Copying classes to > /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error copying artifact from > /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to > /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes > Embedded error: > /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No > such file or directory){noformat} > Steps to reproduce: > * Unpack the attached test project and build the entire project once with > "mvn install". > * Execute "mvn generate-resources" from the root project -> success (because > the compile phase is not executed) > * Execute "mvn package" from the root project -> success (because the package > phase is executed) > * Execute "mvn generate-test-resources" from the root project -> fails > (because the compile phase is executed, but not the package phase) > * Execute "mvn generate-test-resources" in project2 -> success (because the > dependency is not part of the same build) > Root cause analysis: In the scenario described above (compile phase executed, > package phase not executed), Artifact#getFile() points to the target/classes > directory instead of the output artifact. dependency:copy-dependencies > doesn't detect this situation and blindly attempts to execute the copy > operation. This fails with the error message shown above. Note that even if > the operation didn't fail, it would produce an unexpected result. > Proposed fix (see attached patch): Change maven-dependency-plugin to detect > this situation and let it replace the original Artifact object by a new one > resolved from the repository (which would then refer to the artifact > generated by a previous build, exactly as in the mvn generate-resources case). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-105) Classes processed by the relocator still have references to the original classes in their constant pools
[ https://jira.codehaus.org/browse/MSHADE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen updated MSHADE-105: --- Attachment: mshade-105-test.zip I've attached a sample project that shows the issue. It creates a shaded JAR from commons-io and then embeds that JAR into an OSGi bundle using maven-bundle-plugin from Apache Felix. With maven-shade-plugin 1.5 the generated manifest looks as follows (see bundle/target/classes/META-INF/MANIFEST.MF): Manifest-Version: 1.0 Built-By: veithen Created-By: Apache Maven Bundle Plugin Import-Package: org.apache.commons.io,org.apache.commons.io.comparator ,org.apache.commons.io.filefilter,org.apache.commons.io.input,org.apa che.commons.io.output,test Bnd-LastModified: 1331401786401 Export-Package: test Bundle-Version: 1.0.0 Bundle-Name: bundle Bundle-ClassPath: .,shaded-jar-1.jar Build-Jdk: 1.5.0_30 Bundle-ManifestVersion: 2 Bundle-SymbolicName: test.bundle Tool: Bnd-0.0.357 Embed-Dependency: * One can see that there are still references to the original org.apache.commons.io package. With 1.6-SNAPSHOT the manifest looks as expected: Manifest-Version: 1.0 Built-By: veithen Created-By: Apache Maven Bundle Plugin Import-Package: test Bnd-LastModified: 1331401716142 Export-Package: test Bundle-Version: 1.0.0 Bundle-Name: bundle Bundle-ClassPath: .,shaded-jar-1.jar Build-Jdk: 1.5.0_30 Bundle-ManifestVersion: 2 Bundle-SymbolicName: test.bundle Tool: Bnd-0.0.357 Embed-Dependency: * > Classes processed by the relocator still have references to the original > classes in their constant pools > > > Key: MSHADE-105 > URL: https://jira.codehaus.org/browse/MSHADE-105 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Andreas Veithen >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.6 > > Attachments: constant-pool.patch, javap2.txt, javap.txt, > mshade-105-test.zip > > > DefaultShader uses the ClassWriter(ClassReader, int) constructor instead of > ClassWriter(int). According to the ASM Javadoc, this has the following > effects: > "- The constant pool from the original class is copied as is in the new > class, which saves time. New constant pool entries will be added at the end > if necessary, but unused constant pool entries won't be removed. > - Methods that are not transformed are copied as is in the new class, > directly from the original class bytecode (i.e. without emitting visit events > for all the method instructions), which saves a lot of time. Untransformed > methods are detected by the fact that the ClassReader receives MethodVisitor > objects that come from a ClassWriter (and not from a custom ClassAdapter or > any other ClassVisitor instance)." > The second item is actually not applicable in the case of DefaultShader > because the entire class needs to be transformed anyway. On the other hand, > the first item implies that the constant pool of the transformed class will > still have references to the original classes. This can be seen from the > attached "javap.txt" file (produced by javap on a class relocated by > maven-shade-plugin): the relocation adds new entries at the end of the > constant pool, but the original entries are still present. > Since the original entries are no longer referenced anywhere in the class, > this has no consequences at runtime. However, some tools such as Felix' > maven-bundle-plugin use the constant pool to determine the dependencies of a > class. The effect is that if such a shaded JAR is embedded into a bundle > using maven-bundle-plugin, it will generate spurious Import-Package > instructions referring to the original package names. An example of this is > described in AXIS2-5145. > The solution to this problem is simply not to pass the ClassReader object to > the ClassWriter constructor. With this change, the constant pool is properly > cleaned up (see the attached "javap2.txt" file). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-373) Macro snippet with file option in a multi-pom project
[ https://jira.codehaus.org/browse/DOXIA-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293713#comment-293713 ] Andreas Veithen commented on DOXIA-373: --- A workaround for this issue is to use (assuming that the file is a Velocity templete, i.e. has suffix .apt.vm instead of .apt): %{snippet|id=deployment|file=${project.basedir}/src/test/resources/client-config.wsdd} > Macro snippet with file option in a multi-pom project > - > > Key: DOXIA-373 > URL: https://jira.codehaus.org/browse/DOXIA-373 > Project: Maven Doxia > Issue Type: Bug > Environment: Window XP >Reporter: poulfich > > The project is a multi pom project. In the main pom project, I declare the > other pom like this : > > ../moduleA > ../moduleB >... > > To avoid duplicate code,I use the macro snippet in my documentation in > modules A, B and Main. For convenient, the following syntax : > %{snippet|id=myid|file=src/main/java/mypackage/File.java}. > When I build the site from each module A or B, all work fine. But when the > site was generated from the main module, the snippet seem not work : All the > pages who include a snippet's macros in A or B are not generated. I obtain > the same problem if i do a simple site or a site:stage > > The maven site work fine work include pictures and schemas of local > documentation (in A et B). I try to use > the velocity macro and transform MyFile.apt to MyFile.apt.vm like these : > MyFile.apt.vm > %{snippet|id=myid|file=${basedir}/src/main/java/mypackage/File.java}. > It's fail too. > I use maven 2.1.0 > Sorry for my poor english -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-105) Classes processed by the relocator still have references to the original classes in their constant pools
[ https://jira.codehaus.org/browse/MSHADE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293593#comment-293593 ] Andreas Veithen commented on MSHADE-105: Can somebody please review this issue? We have this problem with Apache Axiom, and if the issue is not fixed, we will have to release Axiom with a patched version of the shade plugin. > Classes processed by the relocator still have references to the original > classes in their constant pools > > > Key: MSHADE-105 > URL: https://jira.codehaus.org/browse/MSHADE-105 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Andreas Veithen >Priority: Minor > Attachments: constant-pool.patch, javap2.txt, javap.txt > > > DefaultShader uses the ClassWriter(ClassReader, int) constructor instead of > ClassWriter(int). According to the ASM Javadoc, this has the following > effects: > "- The constant pool from the original class is copied as is in the new > class, which saves time. New constant pool entries will be added at the end > if necessary, but unused constant pool entries won't be removed. > - Methods that are not transformed are copied as is in the new class, > directly from the original class bytecode (i.e. without emitting visit events > for all the method instructions), which saves a lot of time. Untransformed > methods are detected by the fact that the ClassReader receives MethodVisitor > objects that come from a ClassWriter (and not from a custom ClassAdapter or > any other ClassVisitor instance)." > The second item is actually not applicable in the case of DefaultShader > because the entire class needs to be transformed anyway. On the other hand, > the first item implies that the constant pool of the transformed class will > still have references to the original classes. This can be seen from the > attached "javap.txt" file (produced by javap on a class relocated by > maven-shade-plugin): the relocation adds new entries at the end of the > constant pool, but the original entries are still present. > Since the original entries are no longer referenced anywhere in the class, > this has no consequences at runtime. However, some tools such as Felix' > maven-bundle-plugin use the constant pool to determine the dependencies of a > class. The effect is that if such a shaded JAR is embedded into a bundle > using maven-bundle-plugin, it will generate spurious Import-Package > instructions referring to the original package names. An example of this is > described in AXIS2-5145. > The solution to this problem is simply not to pass the ClassReader object to > the ClassWriter constructor. With this change, the constant pool is properly > cleaned up (see the attached "javap2.txt" file). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"
[ https://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen closed MDEP-259. Resolution: Won't Fix I had another look at the issue and it turns out that my proposed change no longer works on Maven 3 because of some subtle changes in the behavior of ArtifactResolver. I don't see any other way to get around this. In my particular case (importing a complex multi-module build into Eclipse) I now recommend users to do this with "mvn -DskipTests=true install eclipse:eclipse" instead of "mvn generate-test-resources eclipse:eclipse". The drawback is that it increases the risk of getting into a chicken-and-egg problem where one wants to refresh the Eclipse project to investigate a build failure but it is not possible to do that because that build failure causes the Maven command used to import the sources into Eclipse to fail... > copy-dependencies fails with "Error copying artifact from .../target/classes > to .../classes" > > > Key: MDEP-259 > URL: https://jira.codehaus.org/browse/MDEP-259 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.0, 2.1 > Environment: Maven 2.0.9 > maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616) >Reporter: Andreas Veithen >Assignee: Brian Fox > Attachments: patch.txt, test-project.zip > > > Scenario: > * dependency:copy-dependencies is used to copy a dependency artifact that is > part of the same multi-module build. > * The compile phase is executed, but not the package phase. > An example of this scenario is using maven-eclipse-plugin to import a Maven > project with generated test (re)sources. In this case, one would execute "mvn > generate-test-resources eclipse:eclipse" to make sure that the generated > (re)sources are imported into the workspace (by default, maven-eclipse-plugin > executes generate-sources and generate-resources, but not > generate-test-sources and generate-test-resources). > Result: The build fails with the following error: > [INFO] [dependency:copy-dependencies {execution: default}] > [INFO] Copying classes to > /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error copying artifact from > /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to > /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes > Embedded error: > /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No > such file or directory) > Steps to reproduce: > * Unpack the attached test project and build the entire project once with > "mvn install". > * Execute "mvn generate-resources" from the root project -> success (because > the compile phase is not executed) > * Execute "mvn package" from the root project -> success (because the package > phase is executed) > * Execute "mvn generate-test-resources" from the root project -> fails > (because the compile phase is executed, but not the package phase) > * Execute "mvn generate-test-resources" in project2 -> success (because the > dependency is not part of the same build) > Root cause analysis: In the scenario described above (compile phase executed, > package phase not executed), Artifact#getFile() points to the target/classes > directory instead of the output artifact. dependency:copy-dependencies > doesn't detect this situation and blindly attempts to execute the copy > operation. This fails with the error message shown above. Note that even if > the operation didn't fail, it would produce an unexpected result. > Proposed fix (see attached patch): Change maven-dependency-plugin to detect > this situation and let it replace the original Artifact object by a new one > resolved from the repository (which would then refer to the artifact > generated by a previous build, exactly as in the mvn generate-resources case). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-105) Classes processed by the relocator still have references to the original classes in their constant pools
Classes processed by the relocator still have references to the original classes in their constant pools Key: MSHADE-105 URL: https://jira.codehaus.org/browse/MSHADE-105 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.4 Reporter: Andreas Veithen Priority: Minor Attachments: constant-pool.patch, javap2.txt, javap.txt DefaultShader uses the ClassWriter(ClassReader, int) constructor instead of ClassWriter(int). According to the ASM Javadoc, this has the following effects: "- The constant pool from the original class is copied as is in the new class, which saves time. New constant pool entries will be added at the end if necessary, but unused constant pool entries won't be removed. - Methods that are not transformed are copied as is in the new class, directly from the original class bytecode (i.e. without emitting visit events for all the method instructions), which saves a lot of time. Untransformed methods are detected by the fact that the ClassReader receives MethodVisitor objects that come from a ClassWriter (and not from a custom ClassAdapter or any other ClassVisitor instance)." The second item is actually not applicable in the case of DefaultShader because the entire class needs to be transformed anyway. On the other hand, the first item implies that the constant pool of the transformed class will still have references to the original classes. This can be seen from the attached "javap.txt" file (produced by javap on a class relocated by maven-shade-plugin): the relocation adds new entries at the end of the constant pool, but the original entries are still present. Since the original entries are no longer referenced anywhere in the class, this has no consequences at runtime. However, some tools such as Felix' maven-bundle-plugin use the constant pool to determine the dependencies of a class. The effect is that if such a shaded JAR is embedded into a bundle using maven-bundle-plugin, it will generate spurious Import-Package instructions referring to the original package names. An example of this is described in AXIS2-5145. The solution to this problem is simply not to pass the ClassReader object to the ClassWriter constructor. With this change, the constant pool is properly cleaned up (see the attached "javap2.txt" file). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"
[ https://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280601#comment-280601 ] Andreas Veithen commented on MDEP-259: -- Providing a test case (as requested by Brian) is still on my todo list, but I didn't find the time yet. > copy-dependencies fails with "Error copying artifact from .../target/classes > to .../classes" > > > Key: MDEP-259 > URL: https://jira.codehaus.org/browse/MDEP-259 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.0, 2.1 > Environment: Maven 2.0.9 > maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616) >Reporter: Andreas Veithen >Assignee: Brian Fox > Attachments: patch.txt, test-project.zip > > > Scenario: > * dependency:copy-dependencies is used to copy a dependency artifact that is > part of the same multi-module build. > * The compile phase is executed, but not the package phase. > An example of this scenario is using maven-eclipse-plugin to import a Maven > project with generated test (re)sources. In this case, one would execute "mvn > generate-test-resources eclipse:eclipse" to make sure that the generated > (re)sources are imported into the workspace (by default, maven-eclipse-plugin > executes generate-sources and generate-resources, but not > generate-test-sources and generate-test-resources). > Result: The build fails with the following error: > [INFO] [dependency:copy-dependencies {execution: default}] > [INFO] Copying classes to > /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error copying artifact from > /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to > /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes > Embedded error: > /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No > such file or directory) > Steps to reproduce: > * Unpack the attached test project and build the entire project once with > "mvn install". > * Execute "mvn generate-resources" from the root project -> success (because > the compile phase is not executed) > * Execute "mvn package" from the root project -> success (because the package > phase is executed) > * Execute "mvn generate-test-resources" from the root project -> fails > (because the compile phase is executed, but not the package phase) > * Execute "mvn generate-test-resources" in project2 -> success (because the > dependency is not part of the same build) > Root cause analysis: In the scenario described above (compile phase executed, > package phase not executed), Artifact#getFile() points to the target/classes > directory instead of the output artifact. dependency:copy-dependencies > doesn't detect this situation and blindly attempts to execute the copy > operation. This fails with the error message shown above. Note that even if > the operation didn't fail, it would produce an unexpected result. > Proposed fix (see attached patch): Change maven-dependency-plugin to detect > this situation and let it replace the original Artifact object by a new one > resolved from the repository (which would then refer to the artifact > generated by a previous build, exactly as in the mvn generate-resources case). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-449) Permissions on directories in a zipped archive incorrect
[ http://jira.codehaus.org/browse/MASSEMBLY-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260084#action_260084 ] Andreas Veithen commented on MASSEMBLY-449: --- A workaround for this issue is to add the following configuration to the plugin: {code} 420 493 493 {code} Tested with 2.2-beta-5. > Permissions on directories in a zipped archive incorrect > > > Key: MASSEMBLY-449 > URL: http://jira.codehaus.org/browse/MASSEMBLY-449 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-4 >Reporter: James Kavanagh > > Using the following assembly plugin: > {code:xml} > > target-packaged > > zip > > false > > > > *:core-env > > > env > false > true > > > > > *:data-bridge > > > target > false > true > > > > > *:web > > > web > false > true > > > > > {code} > When unzipping the result on a Linux host all the directory permissions have > been set to 777. > If I revert the plugin version to 2.2-beta-3 the issue goes away. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"
[ http://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Veithen reopened MDEP-259: -- Sorry Brian, but I have to reopen the issue because your analysis is incomplete: 1. It's not a problem in Maven Core. Maven Core works as designed and the dependency plugin has to take into account how Maven works. The problem is that the dependency plugin makes the assumption that Artifact#getFile() always refers to a plain file and not to a directory. That assumption is wrong, and the minimum would be to add a check and fail the build with a meaningful error message if the artifact refers to a directory. 2. Your enumeration of the possible solutions/workarounds suggests that you neither read the full description of the issue, nor did you have a look at the patch. What I suggest is to "replace the original Artifact object by a new one resolved from the repository (which would then refer to the artifact generated by a previous build, exactly as in the mvn generate-resources case)" if the original Artifact refers to a directory. BTW, I used that approach successfully in a plugin I wrote specifically for Axis2, which does something quite similar to the dependency plugin, but for a highly specialized use case (namely generating an Axis2 repository based on the project dependencies of type aar and mar). See [1]. [1] https://svn.apache.org/repos/asf/axis/axis2/java/core/trunk/modules/tool/axis2-repo-maven-plugin/src/main/java/org/apache/axis2/maven2/repo/AbstractCreateRepositoryMojo.java > copy-dependencies fails with "Error copying artifact from .../target/classes > to .../classes" > > > Key: MDEP-259 > URL: http://jira.codehaus.org/browse/MDEP-259 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.0, 2.1 > Environment: Maven 2.0.9 > maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616) >Reporter: Andreas Veithen >Assignee: Brian Fox > Attachments: patch.txt, test-project.zip > > > Scenario: > * dependency:copy-dependencies is used to copy a dependency artifact that is > part of the same multi-module build. > * The compile phase is executed, but not the package phase. > An example of this scenario is using maven-eclipse-plugin to import a Maven > project with generated test (re)sources. In this case, one would execute "mvn > generate-test-resources eclipse:eclipse" to make sure that the generated > (re)sources are imported into the workspace (by default, maven-eclipse-plugin > executes generate-sources and generate-resources, but not > generate-test-sources and generate-test-resources). > Result: The build fails with the following error: > [INFO] [dependency:copy-dependencies {execution: default}] > [INFO] Copying classes to > /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error copying artifact from > /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to > /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes > Embedded error: > /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No > such file or directory) > Steps to reproduce: > * Unpack the attached test project and build the entire project once with > "mvn install". > * Execute "mvn generate-resources" from the root project -> success (because > the compile phase is not executed) > * Execute "mvn package" from the root project -> success (because the package > phase is executed) > * Execute "mvn generate-test-resources" from the root project -> fails > (because the compile phase is executed, but not the package phase) > * Execute "mvn generate-test-resources" in project2 -> success (because the > dependency is not part of the same build) > Root cause analysis: In the scenario described above (compile phase executed, > package phase not executed), Artifact#getFile() points to the target/classes > directory instead of the output artifact. dependency:copy-dependencies > doesn't detect this situation and blindly attempts to execute the copy > operation. This fails with the error message shown above. Note that even if > the operation didn't fail, it would produce an unexpected result. > Proposed fix (see attached patch): Change maven-dependency-plugin to detect > this situation and let it replace the original Artifact object by a new one > resolved from the repository (which would then refer to the artifact > generated by a previous build, exactly as in the mvn generate
[jira] Commented: (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"
[ http://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=218113#action_218113 ] Andreas Veithen commented on MDEP-259: -- There is a similar issue in maven-war-plugin: MWAR-192. One of the proposed fixes for that issue is to build the artifact on-the-fly from the files in the target/classes folder of the dependency project (see the patch attached to MWAR-192). Something similar could also be implemented for the issue described here, but this would only work for JAR artifacts, not for other packagings (I originally encountered the issue in Axis2 with dependencies on MAR files and in another project with OSGi bundles produced by maven-bundle-plugin from Apache Felix). > copy-dependencies fails with "Error copying artifact from .../target/classes > to .../classes" > > > Key: MDEP-259 > URL: http://jira.codehaus.org/browse/MDEP-259 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy-dependencies >Affects Versions: 2.0, 2.1 > Environment: Maven 2.0.9 > maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616) >Reporter: Andreas Veithen >Assignee: Brian Fox > Attachments: patch.txt, test-project.zip > > > Scenario: > * dependency:copy-dependencies is used to copy a dependency artifact that is > part of the same multi-module build. > * The compile phase is executed, but not the package phase. > An example of this scenario is using maven-eclipse-plugin to import a Maven > project with generated test (re)sources. In this case, one would execute "mvn > generate-test-resources eclipse:eclipse" to make sure that the generated > (re)sources are imported into the workspace (by default, maven-eclipse-plugin > executes generate-sources and generate-resources, but not > generate-test-sources and generate-test-resources). > Result: The build fails with the following error: > [INFO] [dependency:copy-dependencies {execution: default}] > [INFO] Copying classes to > /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error copying artifact from > /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to > /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes > Embedded error: > /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No > such file or directory) > Steps to reproduce: > * Unpack the attached test project and build the entire project once with > "mvn install". > * Execute "mvn generate-resources" from the root project -> success (because > the compile phase is not executed) > * Execute "mvn package" from the root project -> success (because the package > phase is executed) > * Execute "mvn generate-test-resources" from the root project -> fails > (because the compile phase is executed, but not the package phase) > * Execute "mvn generate-test-resources" in project2 -> success (because the > dependency is not part of the same build) > Root cause analysis: In the scenario described above (compile phase executed, > package phase not executed), Artifact#getFile() points to the target/classes > directory instead of the output artifact. dependency:copy-dependencies > doesn't detect this situation and blindly attempts to execute the copy > operation. This fails with the error message shown above. Note that even if > the operation didn't fail, it would produce an unexpected result. > Proposed fix (see attached patch): Change maven-dependency-plugin to detect > this situation and let it replace the original Artifact object by a new one > resolved from the repository (which would then refer to the artifact > generated by a previous build, exactly as in the mvn generate-resources case). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-192) Conflict with workspace resoutlion in m2eclipse
[ http://jira.codehaus.org/browse/MWAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=218111#action_218111 ] Andreas Veithen commented on MWAR-192: -- I think this should be considered a bug in maven-war-plugin and maven-dependency-plugin. MDEP-259 gives a clear explanation of the problem in the context of the maven-dependency-plugin and also shows how to trigger the error from the command line. > Conflict with workspace resoutlion in m2eclipse > --- > > Key: MWAR-192 > URL: http://jira.codehaus.org/browse/MWAR-192 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 > Environment: windows vista >Reporter: Max Powers > Attachments: maven-war-plugin.patch > > > While building my webapp in eclipse using a launch configuration (goals clean > install) and having 'Resolve Workspace Artifacts' checked, the war plugin > cant assemble the war file properly. Note that disabled 'Resolve Workspace > Artifacts' and the war is assembled fine > [DEBUG] Processing: nexus-lvo-plugin-1.3.3-SNAPSHOT.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to copy file for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > > Embedded error: > C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes > (Access is denied) > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to copy file > for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to copy > file for > artifact[org.sonatype.nexus.plugins:nexus-lvo-plugin:jar:1.3.3-SNAPSHOT:compile] > at > org.apache.maven.plugin.war.packaging.ArtifactsPackagingTask.performPackaging(ArtifactsPackagingTask.java:125) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleArtifacts(WarProjectPackagingTask.java:183) > at > org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:103) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 more > Caused by: java.io.FileNotFoundException: > C:\Development\Code\nexus-1.3.x\nexus-core-plugins\nexus-lvo-plugin\target\classes > (Access is denied) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(FileInputStream.java:106) > at > org.codehaus.plexus.util.io.FileInputStreamFacade.getInputSt
[jira] Created: (MDEP-259) copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"
copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes" Key: MDEP-259 URL: http://jira.codehaus.org/browse/MDEP-259 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: copy-dependencies Affects Versions: 2.1, 2.0 Environment: Maven 2.0.9 maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616) Reporter: Andreas Veithen Assignee: Brian Fox Attachments: patch.txt, test-project.zip Scenario: * dependency:copy-dependencies is used to copy a dependency artifact that is part of the same multi-module build. * The compile phase is executed, but not the package phase. An example of this scenario is using maven-eclipse-plugin to import a Maven project with generated test (re)sources. In this case, one would execute "mvn generate-test-resources eclipse:eclipse" to make sure that the generated (re)sources are imported into the workspace (by default, maven-eclipse-plugin executes generate-sources and generate-resources, but not generate-test-sources and generate-test-resources). Result: The build fails with the following error: [INFO] [dependency:copy-dependencies {execution: default}] [INFO] Copying classes to /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error copying artifact from /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes Embedded error: /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No such file or directory) Steps to reproduce: * Unpack the attached test project and build the entire project once with "mvn install". * Execute "mvn generate-resources" from the root project -> success (because the compile phase is not executed) * Execute "mvn package" from the root project -> success (because the package phase is executed) * Execute "mvn generate-test-resources" from the root project -> fails (because the compile phase is executed, but not the package phase) * Execute "mvn generate-test-resources" in project2 -> success (because the dependency is not part of the same build) Root cause analysis: In the scenario described above (compile phase executed, package phase not executed), Artifact#getFile() points to the target/classes directory instead of the output artifact. dependency:copy-dependencies doesn't detect this situation and blindly attempts to execute the copy operation. This fails with the error message shown above. Note that even if the operation didn't fail, it would produce an unexpected result. Proposed fix (see attached patch): Change maven-dependency-plugin to detect this situation and let it replace the original Artifact object by a new one resolved from the repository (which would then refer to the artifact generated by a previous build, exactly as in the mvn generate-resources case). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-389) After running "clean" phase, eclipse detects some errors due to missing folder.
[ http://jira.codehaus.org/browse/MECLIPSE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=192752#action_192752 ] Andreas Veithen commented on MECLIPSE-389: -- A workaround for this issue is to configure the maven-clean-plugin to skip the directory containing the files generated by the eclipse:eclipse goal: maven-clean-plugin 2.3 true ${project.build.directory} generated-resources/eclipse/** > After running "clean" phase, eclipse detects some errors due to missing > folder. > --- > > Key: MECLIPSE-389 > URL: http://jira.codehaus.org/browse/MECLIPSE-389 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.5 >Reporter: pkernevez > > We are using the configuration point out at the bottom of the page : > http://maven.apache.org/plugins/maven-eclipse-plugin/examples/multi-module-projects.html > The presence of the true creates the folder > "target\generated-resources\eclipse\META-INF\" (due to the creation of the > file target\generated-resources\eclipse\META-INF\MANIFEST.MF) during the > "eclipse:eclipse" goal. > First trouble, when we run the phase "clean" this folder is deleted and never > recreated, even if we run other phases (like install). When Eclipse refresh > its folder tree it indicates an error due to this sources missing folder. > Another trouble, is that the name of this Manifest file is hardcoded in the > class EclipseManifestWriter > See > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-eclipse-plugin/src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseManifestWriter.java?revision=618468&view=markup > > The plugin manifest is not used, neither the plugin configuration: > > ${basedir}/src/main/resources/META-INF/MANIFEST.MF > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira