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

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

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.

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.

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.

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.

Someone please fix this. We could really use this.

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

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?

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

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.

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).

Fixed in r1073530.

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

Added basic site docs in r1073533.

Reopening for some additional changes

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

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?

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