[MNGSITE-438] Add guide for Large Scale Centralized Deployments #223
Conversation
content/apt/guides/mini/guide-large-scale-centralized-deployments.apt
Outdated
Show resolved
Hide resolved
| 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. |
There was a problem hiding this comment.
Igore everything below 2.8 and tell that this guide applies to 2.8+
There was a problem hiding this comment.
Because Maven 3.6 still uses maven-deploy-plugin 2.7 as the default version, large organizations with many Maven projects are likely to still be using maven-deploy-plugin 2.7. Even in my own organization, where we've been using this approach for years, we still have projects on maven-deploy-plugin 2.7 (even new projects).
I think the information on how to configure the old maven-deploy-plugin is critical to the target audience of this guide. Maybe in a few years, when the vast majority of projects are upgraded to maven 4.x, where the default version of maven-deploy-plugin has been bumped to 3.x, this information can be removed.
Having said that, I've reworded the sections on the maven-deploy-plugin versions to emphasize usage of 2.8.
There was a problem hiding this comment.
That's wrong. Relying on implicit versions is just wrong and encourage to explicitly ser versions. Advertising documentation for old versions makes life for us hard because we don't support old versions. We request to test with the most recent one. Everyone is obliged to set versions in a parent POM and stick to it. Since 2.8 is the last good version, I will still to this and not advertise anything older.
There was a problem hiding this comment.
I completely agree with @michael-o because not explicitly setting versions for all used plugins is simply the wrong way. Furthermore only using most recent versions in docs.
Apart from that. A simple solution is to use two properties (snapshot/release) (set in your settings.xml which you need anyway to access your repository manager) via your CI and using them in the distributionManagement configuration from within your corporate parent (which you should have; including the versions of plugins defined their apart from other defaults java versions etc). And you can go with the defaults (mvn deploy)...
There was a problem hiding this 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 anymore, 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 (side-note), 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. Perhaps that is a feature request for Maven 4.0.
There was a problem hiding this comment.
Please file a JIRA issue with your feature request. In general project specific targets should be in the POM or inherited if they are general enough.
There was a problem hiding this comment.
Capitalize Maven Reword maven-deploy-plugin version references. Other small improvements
|
@slachiewicz , since all the other guides are in apt, I'd rather keep this one in apt for consistency. I'm focused on the content for now. If it is indeed important to convert to markdown, I'd recommend a followup task to convert all the guides to markdown, not just have this one as a one-off. |
I fully agree here. We strive for consistency and content, rather than formats. |
content/apt/guides/mini/guide-large-scale-centralized-deployments.apt
Outdated
Show resolved
Hide resolved
content/apt/guides/mini/guide-large-scale-centralized-deployments.apt
Outdated
Show resolved
Hide resolved
content/apt/guides/mini/guide-large-scale-centralized-deployments.apt
Outdated
Show resolved
Hide resolved
content/apt/guides/mini/guide-large-scale-centralized-deployments.apt
Outdated
Show resolved
Hide resolved
Switch to repository terms used by nexus (hosted/proxy), instead of the terms used by artifactory (local/remote), to avoid confusion with the local maven repository. Clarify what to do if you want developers to be able to upload artifacts to the repository manager.
Suggested by @michael-o via apache/maven-deploy-plugin#15 (comment)