[ 
https://jira.codehaus.org/browse/MDEPLOY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321965#comment-321965
 ] 

Martin Todorov commented on MDEPLOY-118:
----------------------------------------

In Maven 3.1-SNAPSHOT, the location of the affected code is in 
[DefaultWagonManager|https://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-compat/src/main/java/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java],
 more specifically in the block below:

{code}
    for ( ArtifactMetadata metadata : artifact.getMetadataList() )
    {
        if ( metadata instanceof ProjectArtifactMetadata )
        {
            org.sonatype.aether.artifact.Artifact pomArtifact = new 
SubArtifact( mainArtifact, "", "pom" );
            pomArtifact = pomArtifact.setFile( ( (ProjectArtifactMetadata) 
metadata ).getFile() );
            request.addArtifact( pomArtifact );
        }
        else if ( metadata instanceof SnapshotArtifactRepositoryMetadata
            || metadata instanceof ArtifactRepositoryMetadata )
        {
            // eaten, handled by repo system
        }
        else
        {
            request.addMetadata( new MetadataBridge( metadata ) );
        }
    }
{code}

I believe the first if condition should check if the .pom file already exists 
on the remote server and not add it to deploy request. If I were to fix this, 
could somebody please advise on how to check this and whether using the Wagon's 
resourceExists(...) method is the correct way. (If so, an example of how to use 
it would be highly appreciated).
                
> Enable deployment of attached release artifacts if POM is identical
> -------------------------------------------------------------------
>
>                 Key: MDEPLOY-118
>                 URL: https://jira.codehaus.org/browse/MDEPLOY-118
>             Project: Maven 2.x and 3.x Deploy Plugin
>          Issue Type: Improvement
>    Affects Versions: 2.4
>         Environment: Windows XP SP3
>            Reporter: Bruno F
>              Labels: contributers-welcome
>
> In the context of the build of a native application, one might have 
> zip-artifacts containing several DLL or so files like:
> boost:boost_regex:1.34.1:zip
> In order to distinguish between platforms, it seems to be recommended to use 
> the classifier:
> boost:boost_regex:1.34.1:zip:bin-x86-windows-vc8
> or:
> boost:boost_regex:1.34.1:zip:bin-x86-linux2.6-gcc3.3
> If a Maven repository manager is configured to prevent from re-deploying 
> release artifacts (and I believe it should be), it is not possible to deploy 
> attached artifacts when the POM is the same because the POM is deployed 
> twice. The deploy plugin could check that the POM is already deployed and is 
> the same than the local one (modulo platform-dependent line-break concerns, 
> and that's important!), then choose not to deploy it but only the attached 
> artifact.
> In the example above, it could enable to deploy the 
> boost:boost_regex:1.34.1:zip:bin-x86-windows-vc8 artifact from a Windows 
> machine(coming along with a boost:boost_regex:1.34.1:pom artifact), then to 
> deploy the boost:boost_regex:1.34.1:zip:bin-x86-linux2.6-gcc3.3 artifact from 
> a Linux machine (coming along with the same boost:boost_regex:1.34.1:pom 
> artifact, that will not be deployed since it is identical to the first one 
> deployed).
> Maybe this could be generalized to any kind of artifact? If the artifact to 
> deploy is the same, the plugin should not fail and simply skip the deployment 
> of that artifact?
> I post that bug here on a suggestion of Brett Porter (see the MRM-1357 bug) 
> since it is quite unclear to me whether it is a MRM or deploy plugin concern.
> That bug might also be related to:
> - MDEPLOY-117
> - MDEPLOY-114

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to