philsttr commented on a change in pull request #223: URL: https://github.com/apache/maven-site/pull/223#discussion_r550285056
########## File path: content/apt/guides/mini/guide-large-scale-centralized-deployments.apt ########## @@ -0,0 +1,230 @@ + ------ + Guide to Large Scale Centralized Deployments + ------ + Phil Clay + ------ + 2021-01-01 + ------ + +~~ Licensed to the Apache Software Foundation (ASF) under one +~~ or more contributor license agreements. See the NOTICE file +~~ distributed with this work for additional information +~~ regarding copyright ownership. The ASF licenses this file +~~ to you under the Apache License, Version 2.0 (the +~~ "License"); you may not use this file except in compliance +~~ with the License. You may obtain a copy of the License at +~~ +~~ http://www.apache.org/licenses/LICENSE-2.0 +~~ +~~ Unless required by applicable law or agreed to in writing, +~~ software distributed under the License is distributed on an +~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +~~ KIND, either express or implied. See the License for the +~~ specific language governing permissions and limitations +~~ under the License. + +~~ NOTE: For help with the syntax of this file, see: +~~ http://maven.apache.org/doxia/references/apt-format.html + +Guide to Large Scale Centralized Deployments + + This guide covers an simple optimized approach to using a + {{{../../repository-management.html}repository manager}} + in a large organization. + + The pillars of this approach are: + + [[1]] Use a centralized {{{../../repository-management.html}repository manager}}. + + * Maven clients should download needed artifacts from the repository manager. + + * Maven clients should upload proprietary artifacts to the repository manager. + + [[2]] Configure the location to download/upload artifacts in maven <<<settings.xml>>> files, + rather than in <<<pom.xml>>> files. + + [[3]] Centrally manage the <<<settings.xml>>> files, and distribute them via automation. + + +* {Repository Manager Layout} + + Repository managers generally have at least three types of repositories: + + [local] contains local artifacts uploaded to the repository manager + + [remote] proxies a remote repository and caches artifacts + + [virtual] aggregates several repositories into one + + + The simplest way to organize repositories within a repository manager is + to have a single virtual repository that aggregates: + + * a remote repository for each public repository to mirror. (For example: Maven Central) + + * a local repository for releases + + * a local repository for snapshots + + * a local repository that can contain both releases and snapshots + (see {{{Managing_Uploads_to_the_Repository_Manager}Managing Uploads to the Repository Manager}} for why this repository is needed) + + Separate local repositories are generally used for releases and snapshots + due to the need for different artifact retention policies. + + +* {Managing Downloads from the Repository Manager} + + All artifacts used by maven projects in the organization should be downloaded + via the single virtual repository of the repository manager. + + Maven can be instructed to download artifacts from the repository manager's virtual repository + by defining a mirror in the maven <<<settings.xml>>> file as described in the + {{{./guide-mirror-settings.html}Guide to Mirror Settings}}. + + Example: To download artifacts from the corporate repository manager's <<<maven-virtual>>> repository: + ++-----+ +<settings> + ... + <mirrors> + <!-- Mirror all external repositories via the Corporate Repository Manager's maven virtual repository --> + <mirror> + <id>corp-repository-manager</id> + <name>Corporate Repository Manager</name> + <mirrorOf>external:*</mirrorOf> + <url>https://corp-repository-manager-host/maven-virtual</url> + </mirror> + </mirrors> + ... +</settings> ++-----+ + +* {Managing Uploads to the Repository Manager} + + All proprietary artifacts produced by maven projects in the organization should be uploaded + to the repository manager's local repositories. + + The {{{../../plugins/maven-deploy-plugin}maven-deploy-plugin}} can be instructed to upload artifacts + to the repository manager's repositories by defining the <<<alt*DeploymentRepository>>> properties + in the maven <<<settings.xml>>> file. + + Defining the upload destination of artifacts in <<<settings.xml>>> files rather than + in the <<<distributionManagement>>> section of <<<pom.xml>>> files allows the destinations + to be centrally managed, which simplifies maintenance if the destinations need to change. + In other words, rather than changing a huge number of <<<pom.xml>>> files, + you just need to change {{{Settings_File_Locations}relatively few}} + <<<settings.xml>>> files when the distribution locations need to change. + + The ability to specify a <single> alternate deployment repository via the <<<altDeploymentRepository>>> + property was added in maven-deploy-plugin 2.3. + This single alternate deployment repository is used for both releases and snapshots. + Therefore, a repository capable of hosting release and snapshots artifacts must exist on the repository manager + when using maven-deploy-plugin \>=2.3 and \<2.8. Review comment: I agree that relying on default versions is not the best practice, and I also actively encourage specifying explicit versions. Unfortunately, in a large scale environment, we cannot instantly change all projects to not do it. People will use it because it is easy, or they don't know better, or they aren't that familiar with maven, or they don't even know that the maven-deploy-plugin is being used (since they never use it directly, only CI uses it). I still think how to handle old maven-deploy-plugin versions needs to be mentioned for the guide to be most helpful to the target audience. The people reading the guide will probably have to deal with older projects using older versions of the maven-deploy-plugin, and (like me) cannot instantly upgrade thousands of poms even if they wanted to. And the inability to instantly upgrade thousands of poms is also the reason we don't use `<distributionManagement>` at all in the pom, even with a custom property like @khmarbaise mentioned. The first time we rolled out this change, years ago, we needed to override the existing `<distributionManagement>` section in poms (that did not use a custom property), so we used the properties utilized by maven-deploy-plugin directly, and added properties supported by all versions of maven-deploy-plugin in use. Even if we started today, I'd still use the maven-deploy-plugin's properties, rather than custom properties just so there are no requirements in poms at all. I favor centralizing all of the upload/download configuration in settings.xml files, without anything specific needed in the poms. In fact, I wish there was a `<distributionManagement>` section in the settings.xml file. Since downloads have first-class support in settings.xml files via the mirrors section, it makes logical sense that uploads should also have first-class support in settings.xml files. ---------------------------------------------------------------- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
