philsttr commented on pull request #15: URL: https://github.com/apache/maven-deploy-plugin/pull/15#issuecomment-749776439
Sure thing. We have an artifactory instance in our corporate environment to which we deploy thousands of our own artifacts. This is a large corporate environment that supports many, many dev teams. We do not specify a `distributionManagement` section in our thousands of git repositories. Instead, we specify the `alt*DeploymentRepository` properties in a maven `settings.xml` file ([example](https://github.com/apache/maven-deploy-plugin/files/5731992/settings.xml.txt)) on our CI servers. When the thousands of git repositories are built using these CI servers, they automatically pick up the `alt*DeploymentRepository` values from the maven settings.xml files. This gives us a central place to manage where artifacts are deployed. This approach has proven invaluable at times, since we've gone through a few artifactory migrations, and have had to redirect things several times over the last few years. We want to allow projects to upgrade the version of maven-deploy-plugin used in their projects at their own pace. And we want the builds to continue to work and deploy correctly when they do upgrade maven-deploy-plugin without any other changes to the build pipeline. This transparency requires backwards compatibility of the `alt*DeploymentRepository` value format, since they all use the same settings.xml file. There are several alternatives, but none are very desirable 1. Stop using `alt*DeploymentRepository`, and use `distributionManagement` in each repo, or in parent poms. This requires each repo to be updated any time we need to change the distribution settings. This is not scalable. 2. Create separate settings.xml files for each `alt*DeploymentRepository` value format. This does not allow repos to transparently upgrade maven-deploy-plugin. The builds will break when maven-deploy-plugin is upgraded. The build pipeline for each individual repo would then need to be modified to use different settings.xml file. This is not something I want to expose to the vast majority of other developers, since they do not need to be aware of the distribution management settings to get their job done. In short, not maintaining backwards compatibility of this format will cause us a tremendous amount of toil. That toil can be easily avoided if the format remains backwards compatible. The code to keep backwards compatibility is straightforward and simple, and totally worth it. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
