[jira] [Created] (MNG-7937) Add description of mojo complex object types
Ben Tatham created MNG-7937: --- Summary: Add description of mojo complex object types Key: MNG-7937 URL: https://issues.apache.org/jira/browse/MNG-7937 Project: Maven Issue Type: New Feature Components: Plugin API, Plugin Requests Reporter: Ben Tatham Currently, when a mojo uses "complex types" as parameter types, trying to discover what fields are available in those types,. and that those fields do, is difficult. We rely on external documentation or source code itself. This would be helpful for custom plugins, but also for the common public plugins as well (what are the fields of `Artifact` again?) It would be great if the maven-plugin-plugin generated information about these complex types, hopefully pulling javadoc and/or new annotation information from the type fields themselves. I think this would require updates to a few places: * maven-plugin-plugin to generate the information * the plugin xml itself, to describe these types. * maven-help-plugin to display this information. * plugin report generation to include the type information in the plugin/mojo documentation. * (and then tools/IDE's etc could add features to support this as well with auto-complete, etc) Allowing `@Parameter` (or some new field annotation) on the fields to allow aliases, etc would also be helpful, but perhaps not required/separate feature. An example of documentation that could easily be auto-generated and available via help:describe with this feature: [RuleSet|https://www.mojohaus.org/versions/versions-maven-plugin/version-rules.html#using-the-ruleset-element-in-the-pom]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-63) Remote cache with Nexus raw repository does not work
[ https://issues.apache.org/jira/browse/MBUILDCACHE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735871#comment-17735871 ] Ben Tatham commented on MBUILDCACHE-63: --- !https://fonts.gstatic.com/s/e/notoemoji/15.0/1f926/72.png! The documentation is a bit hidden on the importance of `-Dmaven.build.cache.remote.save.enabled`. That fixes the push to the remote. I still think this bug should be used to get rid of the stack trace when when remote build cache is not found. Seems a bit scary (without -e or -X) to see that stack trace. > Remote cache with Nexus raw repository does not work > > > Key: MBUILDCACHE-63 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-63 > Project: Maven Build Cache Extension > Issue Type: Bug > Components: remote build cache >Affects Versions: 1.0.1 > Environment: Apache Maven 3.9.2 > (c9616018c7a021c1c39be70fb2843d6f5f9b8a1c) > Maven home: /opt/maven/apache-maven > Java version: 19.0.2, vendor: Eclipse Adoptium, runtime: > /opt/java/jdk-19.0.2+7 > Default locale: en_CA, platform encoding: UTF-8 > OS name: "linux", version: "5.19.0-43-generic", arch: "amd64", family: "unix" >Reporter: Ben Tatham >Priority: Major > > I set up a raw repository in Sonatype Nexus to use as the remote build cache. > It seems to connect ok, but the it gets a 404 when looking for the build > cache, and then does not seem to even attempt uploading it when the build is > complete (even though it does save the build cache locally). I assume this > means that the exception at start of the build is disabling the remote cache > being saved later in the build. > I have tried it with and without `dav:` prefix on the url, with same result. > -X gives no further details that I can see. > Let me know if there is anything else I can do to debug this. > {{[INFO] Attempting to restore project > ca.nanometrics.apollo.server:apollo-server-parent from build cache}} > {{[INFO] Downloading > dav:[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml]}} > {{[INFO] Cannot download > dav:[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml]}} > {{org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at > [https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml], > status: 404 > v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml}} > {{ at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData > (AbstractHttpClientWagon.java:1191)}} > {{ at > org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData > (AbstractHttpClientWagon.java:1140)}} > {{ at org.apache.maven.wagon.StreamWagon.getInputStream > (StreamWagon.java:126)}} > {{ at org.apache.maven.wagon.StreamWagon.getIfNewerToStream > (StreamWagon.java:226)}} > {{ at org.apache.maven.wagon.StreamWagon.getToStream > (StreamWagon.java:262)}} > {{ at > org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run > (WagonTransporter.java:427)}} > {{ at org.eclipse.aether.transport.wagon.WagonTransporter.execute > (WagonTransporter.java:367)}} > {{ at org.eclipse.aether.transport.wagon.WagonTransporter.get > (WagonTransporter.java:348)}} > {{ at > org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent > (RemoteCacheRepositoryImpl.java:151)}} > {{ at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild > (RemoteCacheRepositoryImpl.java:108)}} > {{ at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild > (LocalCacheRepositoryImpl.java:169)}} > {{ at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild > (CacheControllerImpl.java:207)}} > {{ at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild > (CacheControllerImpl.java:180)}} > {{ at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute > (BuildCacheMojosExecutionStrategy.java:117)}} > {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:160)}} > {{ at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:105)}} > {{ at > org.apache.maven.lifecycle.internal.Lifecy
[jira] [Updated] (MBUILDCACHE-63) Remote cache with Nexus raw repository does not work
[ https://issues.apache.org/jira/browse/MBUILDCACHE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Tatham updated MBUILDCACHE-63: -- Description: I set up a raw repository in Sonatype Nexus to use as the remote build cache. It seems to connect ok, but the it gets a 404 when looking for the build cache, and then does not seem to even attempt uploading it when the build is complete (even though it does save the build cache locally). I assume this means that the exception at start of the build is disabling the remote cache being saved later in the build. I have tried it with and without `dav:` prefix on the url, with same result. -X gives no further details that I can see. Let me know if there is anything else I can do to debug this. {{[INFO] Attempting to restore project ca.nanometrics.apollo.server:apollo-server-parent from build cache}} {{[INFO] Downloading dav:[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml]}} {{[INFO] Cannot download dav:[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml]}} {{org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at [https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml], status: 404 v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml}} {{ at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData (AbstractHttpClientWagon.java:1191)}} {{ at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData (AbstractHttpClientWagon.java:1140)}} {{ at org.apache.maven.wagon.StreamWagon.getInputStream (StreamWagon.java:126)}} {{ at org.apache.maven.wagon.StreamWagon.getIfNewerToStream (StreamWagon.java:226)}} {{ at org.apache.maven.wagon.StreamWagon.getToStream (StreamWagon.java:262)}} {{ at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run (WagonTransporter.java:427)}} {{ at org.eclipse.aether.transport.wagon.WagonTransporter.execute (WagonTransporter.java:367)}} {{ at org.eclipse.aether.transport.wagon.WagonTransporter.get (WagonTransporter.java:348)}} {{ at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent (RemoteCacheRepositoryImpl.java:151)}} {{ at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild (RemoteCacheRepositoryImpl.java:108)}} {{ at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild (LocalCacheRepositoryImpl.java:169)}} {{ at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild (CacheControllerImpl.java:207)}} {{ at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild (CacheControllerImpl.java:180)}} {{ at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute (BuildCacheMojosExecutionStrategy.java:117)}} {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:160)}} {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)}} {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)}} {{ at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)}} {{ at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)}} {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)}} {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)}} {{ at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)}} {{ at org.apache.maven.cli.MavenCli.execute (MavenCli.java:910)}} {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)}} {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)}} {{ at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104)}} {{ at java.lang.reflect.Method.invoke (Method.java:578)}} {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283)}} {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226)}} {{ at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407)}} {{ at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348)}} {{[INFO] Remote cache is incomplete or missi
[jira] [Created] (MBUILDCACHE-63) Remote cache with Nexus raw repository does not work
Ben Tatham created MBUILDCACHE-63: - Summary: Remote cache with Nexus raw repository does not work Key: MBUILDCACHE-63 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-63 Project: Maven Build Cache Extension Issue Type: Bug Components: remote build cache Affects Versions: 1.0.1 Environment: Apache Maven 3.9.2 (c9616018c7a021c1c39be70fb2843d6f5f9b8a1c) Maven home: /opt/maven/apache-maven Java version: 19.0.2, vendor: Eclipse Adoptium, runtime: /opt/java/jdk-19.0.2+7 Default locale: en_CA, platform encoding: UTF-8 OS name: "linux", version: "5.19.0-43-generic", arch: "amd64", family: "unix" Reporter: Ben Tatham I set up a raw repository in Sonatype Nexus to use as the remote build cache. It seems to connect ok, but the it gets a 404 when looking for the build cache, and then does not seem to even attempt uploading it when the build is complete (even though it does save the build cache locally). I assume this means that the exception at start of the build is disabling the remote cache being saved later in the build. I have tried it with and without `dav:` prefix on the url, with same result. -X gives no further details that I can see. Let me know if there is anything else I can do to debug this. ``` [INFO] Attempting to restore project ca.nanometrics.apollo.server:apollo-server-parent from build cache [INFO] Downloading dav:https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml [INFO] Cannot download dav:https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml, status: 404 v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData (AbstractHttpClientWagon.java:1191) at org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData (AbstractHttpClientWagon.java:1140) at org.apache.maven.wagon.StreamWagon.getInputStream (StreamWagon.java:126) at org.apache.maven.wagon.StreamWagon.getIfNewerToStream (StreamWagon.java:226) at org.apache.maven.wagon.StreamWagon.getToStream (StreamWagon.java:262) at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run (WagonTransporter.java:427) at org.eclipse.aether.transport.wagon.WagonTransporter.execute (WagonTransporter.java:367) at org.eclipse.aether.transport.wagon.WagonTransporter.get (WagonTransporter.java:348) at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent (RemoteCacheRepositoryImpl.java:151) at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild (RemoteCacheRepositoryImpl.java:108) at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild (LocalCacheRepositoryImpl.java:169) at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild (CacheControllerImpl.java:207) at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild (CacheControllerImpl.java:180) at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute (BuildCacheMojosExecutionStrategy.java:117) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:160) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173) at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101) at org.apache.maven.cli.MavenCli.execute (MavenCli.java:910) at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283) at org.apache.maven.cli.MavenCli.main (MavenCli.java:206) at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104) at java.lang.reflect.Method.invoke (Method.java:578) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283) at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407) at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348) [INFO] Remote cache is incomplete or
[jira] [Commented] (MINSTALL-169) Handle non-pom packaging with only a pom artifact
[ https://issues.apache.org/jira/browse/MINSTALL-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245225#comment-17245225 ] Ben Tatham commented on MINSTALL-169: - I took a stab at fixing this, but it is very complicated (and has separate code for install and deploy cases). I found that an easier workaround for a custom lifecycle with a custom plugin is to set the packaging during a mojo itself, which then tricks the install/deploy plugins to do the right thing: For those searching later: ``` @Parameter(defaultValue = "${project}", readonly = true) private MavenProject project; ... project.setPackaging("pom") ``` Note that you should _not_ also set main artifact (`project.setArtifact`) to the pom file, because this will cause the install/deploy mojos to install/deploy the pom twice (which will cause problems on deploy with non-snapshot versions (depending on your repo manager settings). > Handle non-pom packaging with only a pom artifact > - > > Key: MINSTALL-169 > URL: https://issues.apache.org/jira/browse/MINSTALL-169 > Project: Maven Install Plugin > Issue Type: Improvement > Components: install:install >Reporter: Ben Tatham >Priority: Major > > Note: this story affects maven-install-plugin and maven-deploy-plugin equally. > Currently, in > [DefaultProjectInstaller|https://github.com/apache/maven-artifact-transfer/blob/dfb1e61c4f5db6fe167b3d879a37ab5e25c8475c/src/main/java/org/apache/maven/shared/transfer/project/install/internal/DefaultProjectInstaller.java#L82], > if a project does not have literally "pom" as packaging, then if there are > no other artifacts, install:install fails (as does deploy:deploy) with > {code:java} > NoFileAssignedException: The packaging plugin for this project did not assign > a main file to the project but it has attachments. Change packaging to > 'pom'.{code} > > However, for some custom lifecycles (and therefore different packaging > types), we might want to be able to have a lifecycle that just > installs/deploys the pom file alone with no additional artifacts. > Further, if a plugin explicitly sets the main artifact (via > MavenProject.setArtifact) to the `ProjectArtifact`, aka the pom file itself > (which I tried as a work around), then install and deploy perform the same > action twice (which would then break deploy, if the maven central repo blocks > duplicate pushes, as we have setup in our Nexus environment for release > (non-snapshot) artifacts) > Our use case might be weird, but we want to be able to use maven to lookup > version updates for it, even though the artifacts themselves are not in maven > (our use case is docker, helm charts, etc). > I see this as a relatively simple fix in the above mentioned class, and am > happy to contribute a pull request for it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MINSTALL-169) Handle non-pom packaging with only a pom artifact
[ https://issues.apache.org/jira/browse/MINSTALL-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17245225#comment-17245225 ] Ben Tatham edited comment on MINSTALL-169 at 12/7/20, 2:01 PM: --- I took a stab at fixing this, but it is very complicated (and has separate code for install and deploy cases). I found that an easier workaround for a custom lifecycle with a custom plugin is to set the packaging during a mojo itself, which then tricks the install/deploy plugins to do the right thing: For those searching later: {code:java} @Parameter(defaultValue = "${project}", readonly = true) private MavenProject project; ... project.setPackaging("pom") ... {code} Note that you should _not_ also set main artifact (`project.setArtifact`) to the pom file, because this will cause the install/deploy mojos to install/deploy the pom twice (which will cause problems on deploy with non-snapshot versions (depending on your repo manager settings). was (Author: bentat...@nanometrics.ca): I took a stab at fixing this, but it is very complicated (and has separate code for install and deploy cases). I found that an easier workaround for a custom lifecycle with a custom plugin is to set the packaging during a mojo itself, which then tricks the install/deploy plugins to do the right thing: For those searching later: ``` @Parameter(defaultValue = "${project}", readonly = true) private MavenProject project; ... project.setPackaging("pom") ``` Note that you should _not_ also set main artifact (`project.setArtifact`) to the pom file, because this will cause the install/deploy mojos to install/deploy the pom twice (which will cause problems on deploy with non-snapshot versions (depending on your repo manager settings). > Handle non-pom packaging with only a pom artifact > - > > Key: MINSTALL-169 > URL: https://issues.apache.org/jira/browse/MINSTALL-169 > Project: Maven Install Plugin > Issue Type: Improvement > Components: install:install >Reporter: Ben Tatham >Priority: Major > > Note: this story affects maven-install-plugin and maven-deploy-plugin equally. > Currently, in > [DefaultProjectInstaller|https://github.com/apache/maven-artifact-transfer/blob/dfb1e61c4f5db6fe167b3d879a37ab5e25c8475c/src/main/java/org/apache/maven/shared/transfer/project/install/internal/DefaultProjectInstaller.java#L82], > if a project does not have literally "pom" as packaging, then if there are > no other artifacts, install:install fails (as does deploy:deploy) with > {code:java} > NoFileAssignedException: The packaging plugin for this project did not assign > a main file to the project but it has attachments. Change packaging to > 'pom'.{code} > > However, for some custom lifecycles (and therefore different packaging > types), we might want to be able to have a lifecycle that just > installs/deploys the pom file alone with no additional artifacts. > Further, if a plugin explicitly sets the main artifact (via > MavenProject.setArtifact) to the `ProjectArtifact`, aka the pom file itself > (which I tried as a work around), then install and deploy perform the same > action twice (which would then break deploy, if the maven central repo blocks > duplicate pushes, as we have setup in our Nexus environment for release > (non-snapshot) artifacts) > Our use case might be weird, but we want to be able to use maven to lookup > version updates for it, even though the artifacts themselves are not in maven > (our use case is docker, helm charts, etc). > I see this as a relatively simple fix in the above mentioned class, and am > happy to contribute a pull request for it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MINSTALL-169) Handle non-pom packaging with only a pom artifact
Ben Tatham created MINSTALL-169: --- Summary: Handle non-pom packaging with only a pom artifact Key: MINSTALL-169 URL: https://issues.apache.org/jira/browse/MINSTALL-169 Project: Maven Install Plugin Issue Type: Improvement Components: install:install Reporter: Ben Tatham Note: this story affects maven-install-plugin and maven-deploy-plugin equally. Currently, in [DefaultProjectInstaller|https://github.com/apache/maven-artifact-transfer/blob/dfb1e61c4f5db6fe167b3d879a37ab5e25c8475c/src/main/java/org/apache/maven/shared/transfer/project/install/internal/DefaultProjectInstaller.java#L82], if a project does not have literally "pom" as packaging, then if there are no other artifacts, install:install fails (as does deploy:deploy) with {code:java} NoFileAssignedException: The packaging plugin for this project did not assign a main file to the project but it has attachments. Change packaging to 'pom'.{code} However, for some custom lifecycles (and therefore different packaging types), we might want to be able to have a lifecycle that just installs/deploys the pom file alone with no additional artifacts. Further, if a plugin explicitly sets the main artifact (via MavenProject.setArtifact) to the `ProjectArtifact`, aka the pom file itself (which I tried as a work around), then install and deploy perform the same action twice (which would then break deploy, if the maven central repo blocks duplicate pushes, as we have setup in our Nexus environment for release (non-snapshot) artifacts) Our use case might be weird, but we want to be able to use maven to lookup version updates for it, even though the artifacts themselves are not in maven (our use case is docker, helm charts, etc). I see this as a relatively simple fix in the above mentioned class, and am happy to contribute a pull request for it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-36) Dependency reduced pom does not replace the packaged META-INF/maven version
[ https://issues.apache.org/jira/browse/MSHADE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16912828#comment-16912828 ] Ben Tatham commented on MSHADE-36: -- Would fixing this allow the dependency-reduced-pom to be used as the pom of the module in a reactor build? > Dependency reduced pom does not replace the packaged META-INF/maven version > --- > > Key: MSHADE-36 > URL: https://issues.apache.org/jira/browse/MSHADE-36 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Mark Hobson >Priority: Major > > The dependency reduced pom needs to replace the packaged pom at: > META-INF/maven///pom.xml > This will allow tools that use this metadata to read the correct shaded > dependencies (e.g. maven-runtime). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MSHADE-36) Dependency reduced pom does not replace the packaged META-INF/maven version
[ https://issues.apache.org/jira/browse/MSHADE-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16912827#comment-16912827 ] Ben Tatham commented on MSHADE-36: -- Would fixing this allow the dependency-reduced-pom to be used as the pom of the module in a reactor build? > Dependency reduced pom does not replace the packaged META-INF/maven version > --- > > Key: MSHADE-36 > URL: https://issues.apache.org/jira/browse/MSHADE-36 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Mark Hobson >Priority: Major > > The dependency reduced pom needs to replace the packaged pom at: > META-INF/maven///pom.xml > This will allow tools that use this metadata to read the correct shaded > dependencies (e.g. maven-runtime). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (MPH-124) Show parameter aliases in Describe.
Ben Tatham created MPH-124: -- Summary: Show parameter aliases in Describe. Key: MPH-124 URL: https://issues.apache.org/jira/browse/MPH-124 Project: Maven Help Plugin Issue Type: Improvement Reporter: Ben Tatham {{mvn help:describe -Ddetail}} should show the alias as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSHARED-664) Add ico files to default non-filtered extentions
Ben Tatham created MSHARED-664: -- Summary: Add ico files to default non-filtered extentions Key: MSHARED-664 URL: https://issues.apache.org/jira/browse/MSHARED-664 Project: Maven Shared Components Issue Type: Improvement Reporter: Ben Tatham Currently, by default, the following common image/binary file types are non-filtered by default. * jpg,jpeg,gif,bmp,png We should add ico files to this list as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] (MNG-5405) Execute goal does not passes from mojos.xml pluginMetadata
[ https://jira.codehaus.org/browse/MNG-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Tatham updated MNG-5405: Attachment: MNG-5405.patch Here is the simple patch for this bug. Hopefully, we can get it released soon... > Execute goal does not passes from mojos.xml pluginMetadata > -- > > Key: MNG-5405 > URL: https://jira.codehaus.org/browse/MNG-5405 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.0.4 >Reporter: Ben Tatham > Attachments: MNG-5405.patch > > > In pluginMetadata (.mojos.xml) that describes an ant-based plugin, > adding > > foo:bar > > Doesn't make its way in to the plugin.xml. > I tracked down the bug to a missing setter in: > maven-plugin-tools-model-3.2 > org.apache.maven.plugin.tools.model.PluginMetadataParser > line 131 > When copying the LifecycleExecution out of the Mojo into the MojoDescriptor, > it sets the execution lifecycle and phase, but skips the goal. > Trivial fix, not even worth a path, imho. -- 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] (MNG-5405) Execute goal does not passes from mojos.xml pluginMetadata
Ben Tatham created MNG-5405: --- Summary: Execute goal does not passes from mojos.xml pluginMetadata Key: MNG-5405 URL: https://jira.codehaus.org/browse/MNG-5405 Project: Maven 2 & 3 Issue Type: Bug Components: Plugin API Affects Versions: 3.0.4 Reporter: Ben Tatham In pluginMetadata (.mojos.xml) that describes an ant-based plugin, adding foo:bar Doesn't make its way in to the plugin.xml. I tracked down the bug to a missing setter in: maven-plugin-tools-model-3.2 org.apache.maven.plugin.tools.model.PluginMetadataParser line 131 When copying the LifecycleExecution out of the Mojo into the MojoDescriptor, it sets the execution lifecycle and phase, but skips the goal. Trivial fix, not even worth a path, imho. -- 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] (MDEPLOY-144) retry failed deploy does not work on wagon authentication errors
[ https://jira.codehaus.org/browse/MDEPLOY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290712#comment-290712 ] Ben Tatham commented on MDEPLOY-144: Note that one solution to this issue at a higher level would be to do a single authentication with Nexus for all the artifacts to be deployed (all-or-nothing upload of that version). I'm not sure if that's even possible though, without changes to Nexus itself. > retry failed deploy does not work on wagon authentication errors > > > Key: MDEPLOY-144 > URL: https://jira.codehaus.org/browse/MDEPLOY-144 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy >Affects Versions: 2.7 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\tools\maven\apache-maven-3.0.4 > Java version: 1.6.0_29, vendor: Sun Microsystems Inc. > Java home: C:\tools\Java\jdk1.6.0_29\jre > Default locale: en_CA, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Ben Tatham >Priority: Minor > > I have increased the retryFailedDeploymentCount to 10, which does work when I > have seen the upload timeout. > But when webdav wagon returns 401, it does not retry. I can understand why > it wouldn't do that (in most cases, it would just fail again, like if you get > a 400 due to the artifact already existing in Nexus, and even most > authentication failures), but allow me to explain the scenario. > Why I want it to retry: > Oddly, our Nexus installation occasionally fails to properly authenticate > (our IT people say its due to some difference in ActiveDirectory on > WindowsServer 2008 from 2000, and Nexus LDAP does it the 2000 way). > This is very annoying, because it will fail almost always on the 2nd or 3rd > artifact to upload during deployment, which means to properly deploy the > release, we have to either delete the already uploaded artifacts for that > release from Nexus, or do manual deploy-file/via nexus ui of the remaining > artifacts. > I have looked at the code to try and create a patch, but its been hard to > piece together the code paths, as it looks like it depends on the maven > installation, not the dependency hierarchy of maven-deploy-plugin. > Specifically, my guess it is handled inside artifact-manager. > org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put > [INFO] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on > project events: Failed to deploy artifacts: Could not transfer artifact > ca.nanometrics:events:jar:1.1.7 from/to releases > (http://{removed}/nexus/content/repositories/releases): Failed to transfer > file: > http://{removed}/nexus/content/repositories/releases/ca/nanometrics/events/1.1.7/events-1.1.7.jar. > Return code is: 401, ReasonPhrase:Unauthorized. -> [Help 1] -- 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] (MDEPLOY-144) retry failed deploy does not work on wagon authentication errors
Ben Tatham created MDEPLOY-144: -- Summary: retry failed deploy does not work on wagon authentication errors Key: MDEPLOY-144 URL: https://jira.codehaus.org/browse/MDEPLOY-144 Project: Maven 2.x and 3.x Deploy Plugin Issue Type: Improvement Components: deploy:deploy Affects Versions: 2.7 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) Maven home: C:\tools\maven\apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Sun Microsystems Inc. Java home: C:\tools\Java\jdk1.6.0_29\jre Default locale: en_CA, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" Reporter: Ben Tatham Priority: Minor I have increased the retryFailedDeploymentCount to 10, which does work when I have seen the upload timeout. But when webdav wagon returns 401, it does not retry. I can understand why it wouldn't do that (in most cases, it would just fail again, like if you get a 400 due to the artifact already existing in Nexus, and even most authentication failures), but allow me to explain the scenario. Why I want it to retry: Oddly, our Nexus installation occasionally fails to properly authenticate (our IT people say its due to some difference in ActiveDirectory on WindowsServer 2008 from 2000, and Nexus LDAP does it the 2000 way). This is very annoying, because it will fail almost always on the 2nd or 3rd artifact to upload during deployment, which means to properly deploy the release, we have to either delete the already uploaded artifacts for that release from Nexus, or do manual deploy-file/via nexus ui of the remaining artifacts. I have looked at the code to try and create a patch, but its been hard to piece together the code paths, as it looks like it depends on the maven installation, not the dependency hierarchy of maven-deploy-plugin. Specifically, my guess it is handled inside artifact-manager. org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project events: Failed to deploy artifacts: Could not transfer artifact ca.nanometrics:events:jar:1.1.7 from/to releases (http://{removed}/nexus/content/repositories/releases): Failed to transfer file: http://{removed}/nexus/content/repositories/releases/ca/nanometrics/events/1.1.7/events-1.1.7.jar. Return code is: 401, ReasonPhrase:Unauthorized. -> [Help 1] -- 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] Created: (MNG-4677) Plugin configuration incorrectly inherited from parent pom
Plugin configuration incorrectly inherited from parent pom -- Key: MNG-4677 URL: http://jira.codehaus.org/browse/MNG-4677 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.0-beta-1 Reporter: Ben Tatham Until 3.0-beta-1 this was working correctly, but now when I run release:perform, it runs the goals from the un-inherited plugin configuration instead of the one in pluginManagement that should be inherited. In this example, the release plugin on the project should run goals: "deploy nmx-pom:dependency", but instead it is running "deploy nmx-pom:parent". The latter is what the parent pom project itself runs on release. It seems that maven is now ignoring the false flag, at least in some cases. This is confirmed by the effective pom as well (see below). Note that the effective pom in m2eclipse (that must still use the embedded maven instead of the external one I setup in Eclipse Preferences) has it correct. The release goals are all setup by the parent pom, which contains this: ... org.apache.maven.plugins maven-release-plugin 2.0-beta-9 true http://svn/repos/libraries/java/${project.artifactId}/tags false deploy ca.nanometrics.maven:nmx-pom-plugin:dependency -Dpom.update.skip=${pom.update.skip} -Dhudson.url=${hudson.url} -Dhudson.jobName=${hudson.jobName} -Dhudson.buildNumber=${hudson.buildNumber} org.apache.maven.plugins maven-release-plugin 2.0-beta-9 false http://svn/repos/tools/maven/common-pom/tags false deploy ca.nanometrics.maven:nmx-pom-plugin:${nmx-pom-plugin.version}:parent -Dpom.update.skip=${pom.update.skip} -Dhudson.url=${hudson.url} -Dhudson.jobName=${hudson.jobName} -Dhudson.buildNumber=${hudson.buildNumber} The effective pom of the project itself, using 3.0-beta-1 has: ... maven-release-plugin 2.0-beta-9 true http://svn/repos/libraries/java/apollo-workstation/tags false deploy ca.nanometrics.maven:nmx-pom-plugin:dependency -Dpom.update.skip=false -Dhudson.url= -Dhudson.jobName= -Dhudson.buildNumber= maven-release-plugin 2.0-beta-9 false http://svn/repos/libraries/java/apollo/workstation/tags false deploy ca.nanometrics.maven:nmx-pom-plugin:1.3.3:parent -Dpom.update.skip=false -Dhudson.url= -Dhudson.jobName= -Dhudson.buildNumber= ... -- 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] Created: (MCOMPILER-113) Depenent classes end up in target/classes
Depenent classes end up in target/classes - Key: MCOMPILER-113 URL: http://jira.codehaus.org/browse/MCOMPILER-113 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.0.2 Environment: Apache Maven 3.0-alpha-5 (r883378; 2009-11-23 10:53:41-0500) Java version: 1.6.0_17 Java home: C:\java\jdk1.6.0_17\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows xp" version: "5.2" arch: "amd64" Family: "windows" Reporter: Ben Tatham Some extra classes from dependent jars end up in target/classes, and consequently the project artifact jar. Specifically, javax.servlet, from servlet-api:2.4 gets added. This is specified as a provided scope, but even if provided is removed, it still happens. Also reported by others on maven-users list: http://www.mail-archive.com/us...@maven.apache.org/msg101503.html I also tried maven-compiler-plugin:2.1, and with maven 2.2.1. Same results. Adding excludes to maven-compiler-plugin does not stop it from happening (I assume because the classes are not being built by the compiler (b/c not in src/main/java), and so excludes does not apply to them. For now, I've excluded them from the artifact in the maven-jar-plugin: javax\** -- 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: (MASSEMBLY-452) Shared Assembly Descriptor does not work in Maven3-alpha4
[ http://jira.codehaus.org/browse/MASSEMBLY-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200335#action_200335 ] Ben Tatham commented on MASSEMBLY-452: -- Perhaps this issue should be added to: http://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-PluginsMaintainedbytheApacheMavenCommunity > Shared Assembly Descriptor does not work in Maven3-alpha4 > - > > Key: MASSEMBLY-452 > URL: http://jira.codehaus.org/browse/MASSEMBLY-452 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-4 > Environment: Apache Maven 3.0-alpha-4 (r835944; 2009-11-13 > 13:06:31-0500) > Java version: 1.6.0_16 > Java home: C:\java\jdk1.6.0_16\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows xp" version: "5.2" arch: "amd64" Family: "windows" >Reporter: Ben Tatham > Attachments: assemblybug.txt > > > Following these instructions: > http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html > it used to work fine in Maven 2.2.1 and earlier. > With Maven 3.0-alpha-4, see the attached output. -- 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] Created: (MASSEMBLY-452) Shared Assembly Descriptor does not work in Maven3-alpha4
Shared Assembly Descriptor does not work in Maven3-alpha4 - Key: MASSEMBLY-452 URL: http://jira.codehaus.org/browse/MASSEMBLY-452 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-4 Environment: Apache Maven 3.0-alpha-4 (r835944; 2009-11-13 13:06:31-0500) Java version: 1.6.0_16 Java home: C:\java\jdk1.6.0_16\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows xp" version: "5.2" arch: "amd64" Family: "windows" Reporter: Ben Tatham Attachments: assemblybug.txt Following these instructions: http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html it used to work fine in Maven 2.2.1 and earlier. With Maven 3.0-alpha-4, see the attached output. -- 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] Updated: (MSOURCES-44) If project doesn't contain sources (contains only test sources) source:jar will fail
[ http://jira.codehaus.org/browse/MSOURCES-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Tatham updated MSOURCES-44: --- Attachment: failOnEmpty.patch Here is a simple patch to provide a "failOnEmpty" parameter that can be set to false to skip ArchiverException. I could not see a simple way to check if no files are specified before calling the archiver, or to check that this is the reason for the ArchiverException. But it works for me. Note: Must set attach=false to avoid trying to install/deploy a file that does not exist. > If project doesn't contain sources (contains only test sources) source:jar > will fail > > > Key: MSOURCES-44 > URL: http://jira.codehaus.org/browse/MSOURCES-44 > Project: Maven 2.x Source Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: WinXp SP3, Cygwin >Reporter: Bugittaa Pahasti > Attachments: failOnEmpty.patch > > > We are running all of our CI builds with the release profile so that javadocs > and sources are generated. However, one module in a multi-module build > contains only test sources. After updating from 2.0.4 to 2.1 the build will > fail. The same error occurs when source:jar is run manually. Below is the > stack trace from jar:source. It might be intentional that the build will fail > in case source:jar is run from command line, but when using release profile > the failure is quite problematic. > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error creating source archive: You must set at least one file. > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error creating source > archive: You must set at least one file. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523) > 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:597) > 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: Error creating > source archive: You must set at least one file. > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:285) > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:232) > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.execute(AbstractSourceJarMojo.java:201) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 more > Caused by: org.codehaus.plexus.archiver.ArchiverException: You must set at > least one file. > at > org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:260) > at > org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242) > at > org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673) > at > org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:543) > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:277) > ... 20 more -- This message is a
[jira] Commented: (MSOURCES-44) If project doesn't contain sources (contains only test sources) source:jar will fail
[ http://jira.codehaus.org/browse/MSOURCES-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174132#action_174132 ] Ben Tatham commented on MSOURCES-44: We have the same issue, with some test-less projects (like parent pom projects, that are themselves a child pom of our overall company pom that says to create source and test-source jars for all projects, using no-fork goals). > If project doesn't contain sources (contains only test sources) source:jar > will fail > > > Key: MSOURCES-44 > URL: http://jira.codehaus.org/browse/MSOURCES-44 > Project: Maven 2.x Source Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: WinXp SP3, Cygwin >Reporter: Bugittaa Pahasti > > We are running all of our CI builds with the release profile so that javadocs > and sources are generated. However, one module in a multi-module build > contains only test sources. After updating from 2.0.4 to 2.1 the build will > fail. The same error occurs when source:jar is run manually. Below is the > stack trace from jar:source. It might be intentional that the build will fail > in case source:jar is run from command line, but when using release profile > the failure is quite problematic. > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error creating source archive: You must set at least one file. > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error creating source > archive: You must set at least one file. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523) > 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:597) > 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: Error creating > source archive: You must set at least one file. > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:285) > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:232) > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.execute(AbstractSourceJarMojo.java:201) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 more > Caused by: org.codehaus.plexus.archiver.ArchiverException: You must set at > least one file. > at > org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:260) > at > org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242) > at > org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673) > at > org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:543) > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:277) > ... 20 more -- 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] Created: (MRELEASE-434) Assumes scm.url is Current Directory for Remote Tagging
Assumes scm.url is Current Directory for Remote Tagging --- Key: MRELEASE-434 URL: http://jira.codehaus.org/browse/MRELEASE-434 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-9 Reporter: Ben Tatham With the addition of remoteTagging=true, based on the testing I have done, the release plugin is doing a remote tag of the url defined in the scm.url property, which I think comes from developerConnection. If this is incorrect, and that url doesn't exist, than it fails. If this is incorrect, and the url does exist, then the user will get unexpected results, not to mention that you just ran the tests against something different than what will be released (although they will be run again at release:perform) Is this the intended behaviour? Or is my testing taking me to the wrong conclusions? -- 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: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI
[ http://jira.codehaus.org/browse/MSOURCES-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166423#action_166423 ] Ben Tatham commented on MSOURCES-13: I agree -- add it already. But perhaps I'm biased. :) > No-Forking mojos for use within a POM instead of CLI > > > Key: MSOURCES-13 > URL: http://jira.codehaus.org/browse/MSOURCES-13 > Project: Maven 2.x Source Plugin > Issue Type: Improvement >Affects Versions: 2.0.3 > Environment: ALL >Reporter: Ben Tatham > Fix For: 2.1 > > Attachments: nofork.patch, nofork.patch > > > The exiting jar at test-jar mojos will always cause a lifecycle fork and > generate-sources. This can cause all kinds of undesired side effects when > using the source plugin with a pom, instead of CLI. I propose a simple fix > (patch attached) to extend these two mojos in no-forking mode. I can't think > of a better name for them. > This behaviour is similar to the difference between assembly:assembly and > assembly:attached. -- 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: (MREPOSITORY-11) Javadoc not included in the bundle
[ http://jira.codehaus.org/browse/MREPOSITORY-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155038#action_155038 ] Ben Tatham commented on MREPOSITORY-11: --- Please update this page: http://maven.apache.org/guides/mini/guide-central-repository-upload.html to remove the bit about this bug. > Javadoc not included in the bundle > -- > > Key: MREPOSITORY-11 > URL: http://jira.codehaus.org/browse/MREPOSITORY-11 > Project: Maven 2.x Repository Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: Maven version: 2.0.7 > Java version: 1.4.2_13 > OS name: "windows xp" version: "5.1" arch: "x86" >Reporter: Julien HENRY >Assignee: Carlos Sanchez > Fix For: 2.1 > > > On a simple project, I run: > mvn clean source:jar javadoc:jar repository:bundle-create > As a result in target I get: > artifact-version.jar > artifact-version-bundle.jar > artifact-version-javadoc.jar > artifact-version-sources.jar > But in artifact-version-bundle.jar there are only: > META-INF > pom.xml > LICENSE.txt > artifact-version.jar > artifact-version-sources.jar -- 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] Created: (MASSEMBLY-281) Assembly Descriptor from external or parent source
Assembly Descriptor from external or parent source -- Key: MASSEMBLY-281 URL: http://jira.codehaus.org/browse/MASSEMBLY-281 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Reporter: Ben Tatham It would be really convenient if you could easily share assembly descriptors from the parent pom. If the parent pom defines an assembly (likely in pluginManagement), and the descriptor lives in that parent project, then the child should be able to run the same assembly, without having to explicitly download and unpack the parent project dependency. The same fix/feature could be used for other config-file based plugins, like maven-verifier-plugin, as well. -- 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] Created: (MNG-3398) Multiple Plugin Declarations Ignored with no warning
Multiple Plugin Declarations Ignored with no warning Key: MNG-3398 URL: http://jira.codehaus.org/browse/MNG-3398 Project: Maven 2 Issue Type: Bug Components: POM Affects Versions: 2.0.8, 2.0.7 Reporter: Ben Tatham If I (accidentally) declare the same plugin in the pom twice, with different executions,only the executions from the first declaration are run. And no warning is given saying that it is ignoring the others. I figure there are two options to solve this: either use both declarations, or fail the build (fail -- not warning) to tell the user to fix their pom. -- 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: (MCOMPILER-59) Compilation fails on warning messages from javac (Java 6)
[ http://jira.codehaus.org/browse/MCOMPILER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120941 ] Ben Tatham commented on MCOMPILER-59: - I have the same problem on this warning: C:\work\.java:176: warning: sun.misc.Cleaner is Sun proprietary API and may be removed in a future release sun.misc.Cleaner cleaner = (sun.misc.Cleaner) getCleanerMethod ^ If I turn off verbose on the compiler-plugin, it passes the build. With verbose=true, the build gets a Compilation Failure. > Compilation fails on warning messages from javac (Java 6) > - > > Key: MCOMPILER-59 > URL: http://jira.codehaus.org/browse/MCOMPILER-59 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: Mac OSX 10.4.10 > Maven version: 2.0.7 > Java version: 1.6.0-dp > OS name: "mac os x" version: "10.4.10" arch: "i386" > java version "1.6.0-dp" > Java(TM) SE Runtime Environment (build 1.6.0-dp-b88-34) > Java HotSpot(TM) Client VM (build 1.6.0-b88-17-release, mixed mode, sharing) >Reporter: Tim Meighen > Attachments: compiler-warning.tar.gz, warning.tar.gz > > > The attached project fails due to an inability to parse the following warning > messages from the Java compiler (Java 6) > [INFO] Compilation failure > could not parse error message: > /Users/tmeighen/compiler-warning/entity/target/classes/test/MyEntity.class: > warning: Cannot find annotation method 'name()' in type > 'javax.persistence.Table': class file for javax.persistence.Table not found > /Users/tmeighen/compiler-warning/logic/src/main/java/test/Logic.java:7: > warning: [deprecation] deprecateMe() in test.MyEntity has been deprecated > entity.deprecateMe(); > ^ > could not parse error message: > /Users/tmeighen/compiler-warning/entity/target/classes/test/MyEntity.class: > warning: Cannot find annotation method 'name()' in type > 'javax.persistence.Table': class file for javax.persistence.Table not found > /Users/tmeighen/compiler-warning/logic/src/main/java/test/Logic.java:7: > warning: [deprecation] deprecateMe() in test.MyEntity has been deprecated > entity.deprecateMe(); > ^ -- 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: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI
[ http://jira.codehaus.org/browse/MSOURCES-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111754 ] Ben Tatham commented on MSOURCES-13: Yes, exactly. When run from an in a pom, instead of from the cmd line, the generate-sources phase gets run twice. In my case, it causes xdoclet to run twice, which causes other problems. > No-Forking mojos for use within a POM instead of CLI > > > Key: MSOURCES-13 > URL: http://jira.codehaus.org/browse/MSOURCES-13 > Project: Maven 2.x Source Plugin > Issue Type: Improvement > Environment: ALL >Reporter: Ben Tatham > Attachments: nofork.patch, nofork.patch > > > The exiting jar at test-jar mojos will always cause a lifecycle fork and > generate-sources. This can cause all kinds of undesired side effects when > using the source plugin with a pom, instead of CLI. I propose a simple fix > (patch attached) to extend these two mojos in no-forking mode. I can't think > of a better name for them. > This behaviour is similar to the difference between assembly:assembly and > assembly:attached. -- 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] Updated: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI
[ http://jira.codehaus.org/browse/MSOURCES-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Tatham updated MSOURCES-13: --- Attachment: nofork.patch My previous patch was a bit premature. This one actually does what it says. I didn't realize that maven plugin javadoc annotations were inherited! > No-Forking mojos for use within a POM instead of CLI > > > Key: MSOURCES-13 > URL: http://jira.codehaus.org/browse/MSOURCES-13 > Project: Maven 2.x Sources Plugin > Issue Type: Improvement > Environment: ALL >Reporter: Ben Tatham > Attachments: nofork.patch, nofork.patch > > > The exiting jar at test-jar mojos will always cause a lifecycle fork and > generate-sources. This can cause all kinds of undesired side effects when > using the source plugin with a pom, instead of CLI. I propose a simple fix > (patch attached) to extend these two mojos in no-forking mode. I can't think > of a better name for them. > This behaviour is similar to the difference between assembly:assembly and > assembly:attached. -- 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] Created: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI
No-Forking mojos for use within a POM instead of CLI Key: MSOURCES-13 URL: http://jira.codehaus.org/browse/MSOURCES-13 Project: Maven 2.x Sources Plugin Issue Type: Improvement Environment: ALL Reporter: Ben Tatham Attachments: nofork.patch The exiting jar at test-jar mojos will always cause a lifecycle fork and generate-sources. This can cause all kinds of undesired side effects when using the source plugin with a pom, instead of CLI. I propose a simple fix (patch attached) to extend these two mojos in no-forking mode. I can't think of a better name for them. This behaviour is similar to the difference between assembly:assembly and assembly:attached. -- 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] Closed: (MECLIPSE-212) Add POM Schema to pom.xml
[ http://jira.codehaus.org/browse/MECLIPSE-212?page=all ] Ben Tatham closed MECLIPSE-212. --- Resolution: Fixed I put this in the wrong place. Moved to MNGECLIPSE (Maven 2.x Eclipse Extension) > Add POM Schema to pom.xml > - > > Key: MECLIPSE-212 > URL: http://jira.codehaus.org/browse/MECLIPSE-212 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Reporter: Ben Tatham >Priority: Minor > > The POM Editor does not include the XML Schema for POMs in the pom.xml. In > fact, if I add it manually, and then use the "Add Dependency" feature, it > takes it away. > Having the Schema available make it really nice to use the build in XML > Editor features of Eclipse when manually modifying the POM. > This should be an extremely trivial thing to... > http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> instead of just -- 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] Created: (MECLIPSE-212) Add POM Schema to pom.xml
Add POM Schema to pom.xml - Key: MECLIPSE-212 URL: http://jira.codehaus.org/browse/MECLIPSE-212 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Reporter: Ben Tatham Priority: Minor The POM Editor does not include the XML Schema for POMs in the pom.xml. In fact, if I add it manually, and then use the "Add Dependency" feature, it takes it away. Having the Schema available make it really nice to use the build in XML Editor features of Eclipse when manually modifying the POM. This should be an extremely trivial thing to... http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> instead of just -- 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: (MNG-2363) does not work in a multi-project build
[ http://jira.codehaus.org/browse/MNG-2363?page=comments#action_83175 ] Ben Tatham commented on MNG-2363: - I have the same issue, but not using modules. This is the critical point: "Instead, during a multi-project build the profile is either on or off depending on whether the file exists relative to the aggregator pom. The decision is made once." I want a parent pom to define some plugin executions (like xdoclet, jspc, etc), so I can reuse those plugin configurations in all my other projects that need these tools. Of course, that parent project doesn't have servlets/tags/jsps to compile, so I have to use a profile to define them so that I can actually install the pom project itself. But I don't want to have to use a command line property to turn it on...my tests rely on those plugins running. > does not work in a multi-project build > --- > > Key: MNG-2363 > URL: http://jira.codehaus.org/browse/MNG-2363 > Project: Maven 2 > Issue Type: Bug > Components: Profiles >Reporter: David Boden >Priority: Critical > Fix For: 2.1 > > Attachments: problemactivation.zip, screenshot-1.jpg > > > I would expect each subproject to have the profile turned on or off depending > on whether ${basedir}/file-to-check-for exists. > Instead, during a multi-project build the profile is either on or off > depending on whether the file exists relative to the *aggregator pom*. The > decision is made once. > Variable substitution doesn't work, so I can't explicitly use > ${basedir}/file-to-check-for or any variation on this theme > to workaround the bug. > Some background to my particular problem. I have 10 modules to build. Some of > them are GUI modules and contain a file called plugin.xml in the subproject > directory. I want to package these up specially and sign them, ready for > deployment to webstart. The other modules are shared and server code and I > don't want these packaged in the same way. So, I've got a dependency in my > *parent* pom file which activates a profile called "guibundle" if a > plugin.xml file exists in the subproject directory. -- 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