[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
[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
[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=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.MojoExecutor.execute
>
[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=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=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=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=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=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=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=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=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=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=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=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=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=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=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 :
modules
module../moduleA/module
module../moduleB/module
...
/modules
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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=260084#action_260084
]
Andreas Veithen commented on MASSEMBLY-449:
---
A workaround for this issue is to add the following configuration to the plugin:
{code}
configuration
archiverConfig
fileMode420/fileMode !-- 420(dec) = 644(oct) --
directoryMode493/directoryMode !-- 493(dec) = 755(oct) --
defaultDirectoryMode493/defaultDirectoryMode
/archiverConfig
/configuration
{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}
assembly
idtarget-packaged/id
formats
formatzip/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
moduleSets
moduleSet
includes
include*:core-env/include
/includes
binaries
attachmentClassifierenv/attachmentClassifier
includeDependenciesfalse/includeDependencies
unpacktrue/unpack
/binaries
/moduleSet
moduleSet
includes
include*:data-bridge/include
/includes
binaries
attachmentClassifiertarget/attachmentClassifier
includeDependenciesfalse/includeDependencies
unpacktrue/unpack
/binaries
/moduleSet
moduleSet
includes
include*:web/include
/includes
binaries
attachmentClassifierweb/attachmentClassifier
includeDependenciesfalse/includeDependencies
unpacktrue/unpack
/binaries
/moduleSet
/moduleSets
/assembly
{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-resources case).
--
This message is automatically generated by JIRA.
-
If you
[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: (MWAR-192) Conflict with workspace resoutlion in m2eclipse
[ http://jira.codehaus.org/browse/MWAR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.init(FileInputStream.java:106) at org.codehaus.plexus.util.io.FileInputStreamFacade.getInputStream(FileInputStreamFacade.java:78) at
[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-tabpanelfocusedCommentId=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: (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-tabpanelfocusedCommentId=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:
plugin
artifactIdmaven-clean-plugin/artifactId
version2.3/version
configuration
excludeDefaultDirectoriestrue/excludeDefaultDirectories
filesets
fileset
directory${project.build.directory}/directory
excludes
excludegenerated-resources/eclipse/**/exclude
/excludes
/fileset
/filesets
/configuration
/plugin
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 wtpmanifesttrue/wtpmanifest 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=618468view=markup
The plugin manifest is not used, neither the plugin configuration:
manifest
${basedir}/src/main/resources/META-INF/MANIFEST.MF
/manifest
--
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
