Maven Deploy Plugin
  1. Maven Deploy Plugin
  2. MDEPLOY-48

deploy:deploy-file does not support deploying sources jars too

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3
    • Fix Version/s: 2.6
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      deploy:deploy does, but deploy:deploy-file doesn't have a parameter to tell him where the sources jar is:

      mvn deploy:deploy-file -Dfile=$artifactFile -DpomFile=$pomFile -Durl=$toRepo

        Issue Links

          Activity

          Hide
          Geoffrey De Smet added a comment -

          the workaround of scp'ing the sources jar manually isn't that good because it misses out on sha and md5's.

          Show
          Geoffrey De Smet added a comment - the workaround of scp'ing the sources jar manually isn't that good because it misses out on sha and md5's.
          Hide
          Harald Kuhr added a comment -

          It's possible to upload sources via the -Dclassifier=sources switch, the problem with this is it bumps the build-version of snapshots.. So I can't have sources and classes of the same version.

          A workaround is to manually rename the jar, sha and md5 to the latest version after update, but it is of course not a very elegant solution...

          Had a chat with Trygvis last night and he told it should be an easy thing to fix, so I'll expect it done by tomorrow.

          Show
          Harald Kuhr added a comment - It's possible to upload sources via the -Dclassifier=sources switch, the problem with this is it bumps the build-version of snapshots.. So I can't have sources and classes of the same version. A workaround is to manually rename the jar, sha and md5 to the latest version after update, but it is of course not a very elegant solution... Had a chat with Trygvis last night and he told it should be an easy thing to fix, so I'll expect it done by tomorrow.
          Hide
          Arik Kfir added a comment - - edited

          Note that deploy:deploy-file spews an exceptions while deploying an artifact with the -Dclassifier=sources parameter:

          mvn deploy:deploy-file -Dpackaging=jar -DrepositoryId=<keyBasedRepoId> -Durl=scp://myserver.net/var/www/maven -DgroupId=XXX -DartifactId=YYY -Dversion=ZZZ -Dclassifier=sources -DgeneratePom=false -Dfile=FFF

          [INFO] Scanning for projects...
          [INFO] Searching repository for plugin with prefix: 'deploy'.
          [INFO] ----------------------------------------------------------------------------
          [INFO] Building Maven Default Project
          [INFO]    task-segment: [deploy:deploy-file] (aggregator-style)
          [INFO] ----------------------------------------------------------------------------
          [INFO] [deploy:deploy-file]
          Uploading: scp://codeshine.net/var/www/maven/de/odysseus/juel/juel-impl/2.1.0/juel-impl-2.1.0-sources.jar
          60K uploaded
          [INFO] Retrieving previous metadata from codeshine
          [INFO] ------------------------------------------------------------------------
          [ERROR] FATAL ERROR
          [INFO] ------------------------------------------------------------------------
          [INFO] null
          [INFO] ------------------------------------------------------------------------
          [INFO] Trace
          *java.lang.NullPointerException
                  at hidden.org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:842)
                  at org.apache.maven.project.artifact.ProjectArtifactMetadata.storeInLocalRepository(ProjectArtifactMetadata.java:86)
                  at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java: 428)
                  at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:86)
                  at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:239)
                  at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
                  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
                  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
                  at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
                  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)*
          [INFO] ------------------------------------------------------------------------
          [INFO] Total time: 42 seconds
          [INFO] Finished at: Tue Nov 27 12:00:53 IST 2007
          [INFO] Final Memory: 3M/6M
          [INFO] ------------------------------------------------------------------------
          

          The actual deployment of the artifact to the remote server succeeds - it fails when (apparently) trying to install the file as well.

          Show
          Arik Kfir added a comment - - edited Note that deploy:deploy-file spews an exceptions while deploying an artifact with the -Dclassifier=sources parameter: mvn deploy:deploy-file -Dpackaging=jar -DrepositoryId=<keyBasedRepoId> -Durl=scp://myserver.net/var/www/maven -DgroupId=XXX -DartifactId=YYY -Dversion=ZZZ -Dclassifier=sources -DgeneratePom=false -Dfile=FFF [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'deploy'. [INFO] ---------------------------------------------------------------------------- [INFO] Building Maven Default Project [INFO] task-segment: [deploy:deploy-file] (aggregator-style) [INFO] ---------------------------------------------------------------------------- [INFO] [deploy:deploy-file] Uploading: scp://codeshine.net/var/www/maven/de/odysseus/juel/juel-impl/2.1.0/juel-impl-2.1.0-sources.jar 60K uploaded [INFO] Retrieving previous metadata from codeshine [INFO] ------------------------------------------------------------------------ [ERROR] FATAL ERROR [INFO] ------------------------------------------------------------------------ [INFO] null [INFO] ------------------------------------------------------------------------ [INFO] Trace *java.lang.NullPointerException at hidden.org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:842) at org.apache.maven.project.artifact.ProjectArtifactMetadata.storeInLocalRepository(ProjectArtifactMetadata.java:86) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.deploy(DefaultRepositoryMetadataManager.java: 428) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:86) at org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:239) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) 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)* [INFO] ------------------------------------------------------------------------ [INFO] Total time: 42 seconds [INFO] Finished at: Tue Nov 27 12:00:53 IST 2007 [INFO] Final Memory: 3M/6M [INFO] ------------------------------------------------------------------------ The actual deployment of the artifact to the remote server succeeds - it fails when (apparently) trying to install the file as well.
          Hide
          James Kingsbery added a comment -

          Is there progress on this? I got the same behavior as Arik. My company will need this feature, so I'd be willing to fix it if no one's started working on it.

          Show
          James Kingsbery added a comment - Is there progress on this? I got the same behavior as Arik. My company will need this feature, so I'd be willing to fix it if no one's started working on it.
          Hide
          Duncan Doyle added a comment -

          I would like to see this option included as well. James, have you already started with a fix? If so, could you send me the source code so I can build my own deploy plugin.

          Show
          Duncan Doyle added a comment - I would like to see this option included as well. James, have you already started with a fix? If so, could you send me the source code so I can build my own deploy plugin.
          Hide
          Daniel Norton added a comment -

          Why is this still unassigned after 18 months? Maybe it's not really a major priority. In any case, I would like to see resolution on this if possible.

          Show
          Daniel Norton added a comment - Why is this still unassigned after 18 months? Maybe it's not really a major priority. In any case, I would like to see resolution on this if possible.
          Hide
          Philip Schlesinger added a comment -

          Someone please fix this. We could really use this.

          Show
          Philip Schlesinger added a comment - Someone please fix this. We could really use this.
          Hide
          Brandon Goodin added a comment -

          http://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html

          Deploying Source Jars

          To deploy a 3rd party source jar, packaging should be set to java-source, and generatePom should be set to false.

          Works for me

          Show
          Brandon Goodin added a comment - http://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html Deploying Source Jars To deploy a 3rd party source jar, packaging should be set to java-source, and generatePom should be set to false. Works for me
          Hide
          James Kingsbery added a comment -

          Brandon's fix did not seem to work for me, however, this did:

          http://www.mail-archive.com/users@maven.apache.org/msg66181.html

          Is it documented anywhere that the deploy plugin does this? What are its criteria for knowing what in the target directory it should upload?

          Show
          James Kingsbery added a comment - Brandon's fix did not seem to work for me, however, this did: http://www.mail-archive.com/users@maven.apache.org/msg66181.html Is it documented anywhere that the deploy plugin does this? What are its criteria for knowing what in the target directory it should upload?
          Hide
          Markus Nolte added a comment -

          Just had the same problem - my workaround ist to deploy source and jar both with with -DuniqueVersion=false

          Show
          Markus Nolte added a comment - Just had the same problem - my workaround ist to deploy source and jar both with with -DuniqueVersion=false
          Hide
          Bob Fields added a comment -

          Problem still exists, and the -DuniqueVersion=false workaround sortof works, however if you are pointing to an existing pom file for the initial deploy, and then point to the same pom file for the -sources deploy, the -sources.jar archive is deployed, however it gives an error when trying to deploy the pom file again (correctly): [INFO] Error installing artifact's metadata: Error while deploying metadata: Failed to transfer file: http://xxx.pom. Returncode is: 400. Workaround is to specify the -DGAV individually, instead of the pom.

          I know there's a way to tell it not to generate a pom. Is there a way to tell it not to deploy the pom (since it already exists), but still be able to use the GAV information contained in the pom instead of specifying all on the command line? Or better yet, add the options to specify a sources and javadoc archives at the same time as the runtime deploy.

          Show
          Bob Fields added a comment - Problem still exists, and the -DuniqueVersion=false workaround sortof works, however if you are pointing to an existing pom file for the initial deploy, and then point to the same pom file for the -sources deploy, the -sources.jar archive is deployed, however it gives an error when trying to deploy the pom file again (correctly): [INFO] Error installing artifact's metadata: Error while deploying metadata: Failed to transfer file: http://xxx.pom . Returncode is: 400. Workaround is to specify the -DGAV individually, instead of the pom. I know there's a way to tell it not to generate a pom. Is there a way to tell it not to deploy the pom (since it already exists), but still be able to use the GAV information contained in the pom instead of specifying all on the command line? Or better yet, add the options to specify a sources and javadoc archives at the same time as the runtime deploy.
          Hide
          Brett Porter added a comment -

          not at present, but the issue is being left open for patching.

          You'll be encouraged to know that the current trunk of Maven 3 supports subsequent uploads for snapshots with classifiers that will be resolved correctly (see MNG-4452).

          Show
          Brett Porter added a comment - not at present, but the issue is being left open for patching. You'll be encouraged to know that the current trunk of Maven 3 supports subsequent uploads for snapshots with classifiers that will be resolved correctly (see MNG-4452 ).
          Hide
          Paul Gier added a comment -

          Fixed in r1073530.

          Added new mojo parameters "sources" and "javadoc" to match the behaviour of the install plugin.

          Show
          Paul Gier added a comment - Fixed in r1073530 . Added new mojo parameters "sources" and "javadoc" to match the behaviour of the install plugin.
          Hide
          Paul Gier added a comment -

          Added basic site docs in r1073533.

          Show
          Paul Gier added a comment - Added basic site docs in r1073533 .
          Hide
          Paul Gier added a comment -

          Reopening for some additional changes

          Show
          Paul Gier added a comment - Reopening for some additional changes
          Hide
          Paul Gier added a comment -

          Finished re-factoring to work with Maven 2.x in r1074207.

          Show
          Paul Gier added a comment - Finished re-factoring to work with Maven 2.x in r1074207 .
          Hide
          Ruben Garat added a comment - - edited

          Hi, would it be reasonable to have support for an arbitrary number of attached artifacts?

          I have to deploy some artifacts that have the main jar, javadoc, sources, and different artifacts for natives for different OS using classifiers to indicate the OS.
          In this case I still have the same problem that this but tried to solve for the natives, and there is no good solution that supports maven 2 and maven 3 for deploying this artifacts as separate steps (if I use uniqueVersions=false then maven 3 doesn't update the snapshots even when forcing it, if I use uniqueVersion=true then when using maven 2 it fails to resolve the main jar because the pom has a different timestamp than the jar)

          something like:
          -attached classifier:artifactpath

          and allowing this command to be repeated would work I think.

          EDIT: is this request ok here, or should I create another issue?

          Show
          Ruben Garat added a comment - - edited Hi, would it be reasonable to have support for an arbitrary number of attached artifacts? I have to deploy some artifacts that have the main jar, javadoc, sources, and different artifacts for natives for different OS using classifiers to indicate the OS. In this case I still have the same problem that this but tried to solve for the natives, and there is no good solution that supports maven 2 and maven 3 for deploying this artifacts as separate steps (if I use uniqueVersions=false then maven 3 doesn't update the snapshots even when forcing it, if I use uniqueVersion=true then when using maven 2 it fails to resolve the main jar because the pom has a different timestamp than the jar) something like: -attached classifier:artifactpath and allowing this command to be repeated would work I think. EDIT: is this request ok here, or should I create another issue?
          Hide
          Paul Gier added a comment -

          Hi Ruben, you should create a new issue since this one is already closed.

          Show
          Paul Gier added a comment - Hi Ruben, you should create a new issue since this one is already closed.

            People

            • Assignee:
              Paul Gier
              Reporter:
              Geoffrey De Smet
            • Votes:
              10 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: