[MDEPLOY-118] Enable deployment of attached release artifacts if POM is identical

[sos-jira-migration-bot]

Bruno Freudensprung opened MDEPLOY-118 and commented

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

---

Affects: 2.4

Issue Links:

• MDEPLOY-117 Use GAV from specified pomFIle but not deploy the pom

• MRM-1357 Allow deployment of attached release artifacts if POM is identical

• MDEPLOY-154 Rewrite page 'deploy with classifier'

• MDEPLOY-114 Add an option to not fail when remote file already exists and redeploy is forbidden

• MDEPLOY-156 Add flag to 'ignoreReleaseDeployErrors' to ease multi module release builds with classifiers.
  ("supercedes")

• MDEPLOY-126 Deploy only artifacts which have been explicitly attached
  ("supercedes")

Remote Links:

• GitHub Pull Request #28
  

1 votes, 3 watchers

[sos-jira-migration-bot]

Stephen Connolly commented

Could use the .MD5 and .SHA1 side artifacts to check if the artifact is the same

[sos-jira-migration-bot]

Martin Todorov commented

In your case you're only referring to OS-s. However, this is a general classifier problem.

What appears to be happening is that the .pom file gets re-deployed every time you want to invoke the deploy-file goal on the same artifactId but with a different classifier. I believe this behavior should be changed in such a way that if the artifact you're deploying has a classifier, then the plugin should check if the .pom has already been deployed to the remote host. If it has been, well, then just don't over-write it and things will be okay. It doesn't make sense to enable artifact re-deployment in your artifact repository manager just so that one could workaround this bug.

Could somebody please have a look at this? Many thanks in advance!

P.S.: I've tested this against 2.7.

[sos-jira-migration-bot]

Martin Todorov commented

In Maven 3.1-SNAPSHOT, the location of the affected code is in DefaultWagonManager, more specifically in the block below:

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 ) );
    }
}

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

[sos-jira-migration-bot]

scolebourne2 commented

Fixing this would definitely be helpful to me, as outlined in the similar use case motivating MDEPLOY-160.

[sos-jira-migration-bot]

Martin Todorov commented

Checking if an artifact exists can be done using the WagonDownload.exists() method. More details can be found here.

[sos-jira-migration-bot]

Michael Osipov commented

This issue has been auto closed because it has been inactive for a long period of time. If you think this issue still applies, retest your problem with the most recent version of Maven and the affected component, reopen and post your results.

[sos-jira-migration-bot]

Elliotte Rusty Harold commented

Active PR for this issue has been submitted

[sos-jira-migration-bot]

Elliotte Rusty Harold commented

It MIGHT be OK to upload new artifacts with new classifiers to an existing deployment.

Under no circumstances is it OK to upload new versions of existing artifacts. You can't upload a new jar without changing the coordinates.