I totally agree with that. If you run into any problems with that please reach out to me and I can help in detail as I wrote most of the linked docs and also created a video series with tips and just recently did a fully automated setup with Atlassian Pipelines for example.
http://www.sonatype.org/nexus/2016/05/24/sonatype-automated-deployments-with-atlassian-bitbucket-pipelines/ Manfred Jeff Jensen wrote on 2016-05-13 05:13: >> >> I want to offer my library also via a Maven repository - snapshots as well >> as releases. > > > Use Sonatype's free OSS repo hosting [0]. It also provides the easiest and > fastest path for deploying artifacts into Central. > > Essentially: > 1. Deploy snapshots and releases to it. > 2. Promote successful releases from it to Central when desired. > > > [0] http://central.sonatype.org/pages/ossrh-guide.html > > > On Fri, May 13, 2016 at 2:16 AM, Barrie Treloar <[email protected]> wrote: > >> A snapshot repository won't behave how you think it will behave. >> I recommend not providing one. >> >> As a developer you want your code base to be in a known configured state. >> Having a snapshot repository will mean that Maven will pull in a new >> snapshot occasionally (you have some control over when they might be) and >> if that snapshot is SNAFU then you have just stopped that developer from >> being productive. If a developer wants a snapshot let them pull your code >> down and built it themselves, then if the code is SNAFU they can choose a >> previous revision from source control to use instead. >> >> Since you are talking about a sourceforge project then you are providing an >> open source, so you are better off deploying your releases to central. >> Your users will thank you for not slowing their build times down with your >> custom repo. >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
