[
https://jira.codehaus.org/browse/MDEPLOY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321815#comment-321815
]
Martin Todorov commented on MDEPLOY-118:
----------------------------------------
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!
> 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:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
