Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of t.broyer@gmail.com designates
 209.85.215.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <22D87C23-9935-4888-A55A-E9BE99C4BC6D@natusoft.se>
References: <80577B10-8927-4E40-9E41-5B69DBC66977@natusoft.se>
 <54D3CE24C875604ABE7E6722C0EB885416340C9206@QUIPSY1.Quipsy.local>
 <22D87C23-9935-4888-A55A-E9BE99C4BC6D@natusoft.se>
From: Thomas Broyer <t.broyer@gmail.com>
Date: Sun, 5 Jan 2014 21:06:27 +0100
Message-ID: 
 <CAEayHENZ0_FDjDMAHp=rB7LMNsocBzOsa4r0zyOfr61JkDGj5A@mail.gmail.com>
Subject: Re: Maven Central Opinion
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=089e013c6640e28c0204ef3eae0b

--089e013c6640e28c0204ef3eae0b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 5, 2014 at 5:29 PM, Tommy Svensson <tommy@natusoft.se> wrote:

> Well, I guess I have my answer, I am alone :-).
>
> Many people are telling me that both the sonatype super pom and SNAPSHOTs
> are optional. I obviously have been reading the wrong instructions.


Maven dependency versionning is based on snapshots and releases, with
releases that cannot change once published (if you messed up with your 1.0,
you have to release a 1.0.1 (or whatever version you want))
That doesn't mean you *have* to publish snapshots, and that doesn't even
mean you have to use snapshot versions in your POM.
But consider the pros and cons of not using snapshots: if your POM doesn't
use a snapshot version, then anyone cloning your repo and doing a "mvn
install" will have in its local repo the artifact it just built, and then
when you publish that release yourself, that developer won't see it
(because Maven won't check for a more recent version: non-snapshot versions
do not change from Maven point of view =E2=80=93 OK, it might no longer be =
true
with recent versions of Maven, where the version is tied to the repo it
comes from, IIRC).

I agree the doc is strongly biased towards using sonatype-parent though,
but as others pointed out, this is not a requirement (see
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+=
Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement
)

I think the doc is for people who don't really know what they're doing and
don't really want to know and just want to proceed, and sonatype-parent and
the maven-release-plugin make it really easier for them.
If you don't want to use the sonatype-parent parent, then you'll have to
invest time into understanding what you have to do ("Central Sync
Requirement") and how to configure your POM to achieve it.
Similarly if you don't want to use the maven-release-plugin.

Are there better, clearer instructions somewhere else ? One of the "mvn
> release:*" commands (dont rember which ) failed if I did not have a
> SNAPSHOT version and told me the problem was that I did not have a SNAPSH=
OT
> version. So is the above page completely wrong ? Are there other "mvn
> release:*" goals to run ?
>

The maven-release-plugin is *one* way (the preferred way) to release
artifacts, but it's actually only a big workflow that calls into other
plugins: update the POMs with a non-snapshot version, verify that it
builds, commit the change and tag the commit, deploy to the remote repo,
then change the POMs to a snapshot version, verify that it builds, and
commit the change.
You're not forced to use the maven-release-plugin to release artifacts, you
can do some or all of the above steps "by hand", and you could use
non-snapshot versions all the time (but then you *cannot* use the
maven-release-plugin).

Again, the maven-release-plugin makes it simpler if you follow the rules
(use snapshot versions) and accept the conditions; you're not forced to use
it but you'll have to invest time into understanding what it does (that is
mandatory or optional) and how to do (some of) it by other means.

As I said in a previous message, deploying to the remote repo is just a
matter of "mvn deploy", using either the maven-deploy-plugin (by default)
or the nexus-staging-maven-plugin.
You'll have to configure the GPG plugin to sign your artifacts though, as
it's a requirement to deploy to Central.

I bet you'll find many blogs online about how to do releases without the
maven-release-plugin, and how to then deploy to Central.


> Many of the responses to my mail have also indicated that the update of m=
y
> github repository is a totally obvious thing. I simply do not accept that=
.
> When I update my repository and what I update it with is my and only my
> decision! I went around this problem by making a copy repository before
> going through the release steps, and then deleted the copy afterwards,
> keeping my original intact. It was already in the state I wanted it befor=
e
> releasing to maven central. The only thing I want to release to maven
> central is binaries! My repository should not be touched. So if there is =
no
> way around that happening I guess I have released my first and last code =
to
> maven central.
>

The maven-release-plugin has many configuration properties related to SCM:
whether to push changes, tag changes, etc.
http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.htm=
l

Note, I never tried it but you could apparently just do "mvn
release:perform -DconnectionUrl=3D=E2=80=A6" (or creating a release.propert=
ies file
and then using "mvn release:perform"):
http://maven.apache.org/maven-release/maven-release-plugin/examples/perform=
-release.html

--089e013c6640e28c0204ef3eae0b--