cstamas commented on issue #1440: URL: https://github.com/apache/maven-site/issues/1440#issuecomment-3431347713
Originally in 2000s the "deploy" happened against single server (just look at old ASF parents, **[apache-parent-4](https://repo.maven.apache.org/maven2/org/apache/apache/4/apache-4.pom)** for example), and things like scp/sftp/etc were used. Later, with advent of MRMs (again, look at ASF parents, **[apache-parent-5](https://repo.maven.apache.org/maven2/org/apache/apache/5/apache-5.pom)** for example that was first using RAO) were pointing to some service URL, that already lacked information: that alone is not enough information anymore for deployment, as deployment ended up in staging repository, you had to know which one, it needed extra (manual, outside work) from user: close it, release it, wait for sync, etc. But, still "deployment with workflow" happened (that was either finished manually as in ASF, close repo + vote + release repo; or some plugin handled the proprietary APIs - but you still had "something happening outside of m-deploy-p scope"). Today, I am pushing to distinguish between _publishing_ and _deploying_ projects. Projects that "deploy" (right now ASF ones, but also some in-house development that deploys to in-house MRM) will continue to use m-deploy-p. But, projects _publishing_ need even more information (aka configuration), and those cannot be expressed with single URL (+ auth), but needs way more. So, in essence, it boils down what you do: deploy or publish? You can still continue to do both, but sometimes it is unlikely. Typical example are OSS projects outside of some umbrella (outside of ASF, Eclipse, that do have their own MRMs that takes over that "deploy with workflow" part). Just pick any of those "standalone" projects, for example FasterXML (Jackson org). This project _publishes_ to Central, and has no "forge" (like ASF or Eclipse or any, so no "repo infra"). Their POM contains Sonatype CP service URL, that again, does not tells anything about _where the artifacts are ending up_. Hence, the "use of single URL to configure publishing" is not enough anymore. tl;dr: depends on what you do (what your project does): * if you "deploy" (as all Maven projects did so far), but today it implies you have some "repo infra" (usually in-house MRM), then for you all remains same as before, as you are targeting your MRM, and your MRM _may perform some extra workflow for you_ * if you "publish" (and not deploy anymore), like "standalone OSS projects do to Central", then as I explained above, the whole publishing is anyway not configurable via single URL, and today used service URLs are really not giving any (valuable/usable) information. Moreover, it requires tools like CycloneDX to "figure out" which service URL means which _actual repository_. Note: "publish like setup" (where your POM distributionMgmgt contains "real target URL where artifacts will be available") are still doable even with "deploy" scenario: just define a property for `altDeploymentRepository` in POM properties, and configure `m-deploy-p` with that (so override value that `m-deploy-p` would go directly for, the POM distributionManagement). -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
