Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
From: Charles Honton <chas@honton.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_417CFF55-39EB-4B92-8BA6-23EE830F27B5"
Subject: [ALL] Changing the commons process 
Message-Id: <27690FD8-1EAB-4D68-9118-99B971A5428A@honton.org>
Date: Fri, 23 Dec 2016 12:54:14 -0800
To: Commons Developers List <dev@commons.apache.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
archived-at: Fri, 23 Dec 2016 20:54:35 -0000

--Apple-Mail=_417CFF55-39EB-4B92-8BA6-23EE830F27B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Several recent email threads have discussed our parent pom and release =
process.  The process we have derive from Apache Common=E2=80=99s rich =
history which pre-dates many current distribution practices.  I=E2=80=99d =
like to summarize several quirks with our current releases:
The official release source tarball contains just the sources, not all =
the project files.  Building the artifact from just the src directory =
without the pom would be extremely difficult.
The commons parent pom attaches the source tarball to the maven release =
for the side effects of signing/checksumming the source tarball.  This =
induces a manual step of removing the source tarballs from the staging =
repository.
We publish convenience binaries to =
https://www.apache.org/dist/commons/XXX/binaries.  I doubt anyone =
consumes these binaries.  Most developers use Maven Central.  Extremely =
security conscious downstream projects consume the distribution source =
tarballs.
The distribution artifacts are doubled in size by providing both .zip =
and tar.gz versions.
Slightly different artifacts are published to Apache Distribution Site =
vs Maven Central.

Now the questions:

1. Are there any concerns with publishing the source and source-test =
jars produced by maven-source-plugin as the official distribution =
artifacts?  This would make the official distribution artifacts =
published to https://www.apache.org/dist/commons/XXX/source the same as =
the convenience source artifacts published to Maven Central.

2. Are there concerns with not publishing the convenience binaries to =
https://www.apache.org/dist/commons/XXX/binaries?  Alternatively, are =
there concerns with using the the jar produced by maven-jar-plugin as =
the convenience binary artifact?  This would make the convenience binary =
artifact published to https://www.apache.org/dist/commons/XXX/binaries =
the same as the convenience binary artifacts published to Maven Central.

Some background information to help contemplate these questions:

When releasing a package, Apache Commons publishes the official source =
tarball at https://www.apache.org/dist/commons/XXX/source.  The Apache =
Release Policy =
<http://www.apache.org/dev/release.html#what-must-every-release-contain> =
and Release Signing Policy =
<http://www.apache.org/dev/release-distribution.html#sigs-and-sums> =
require:
=E2=80=9CEvery ASF release must contain a source package, which must be =
sufficient for a user to build and test the release provided they have =
access to the appropriate platform and tools=E2=80=9D
"Every artifact distributed to the public through Apache channels MUST =
be accompanied by one file containing an OpenPGP compatible ASCII =
armored detached signature and another file containing an MD5 =
checksum.=E2=80=9D (.asc file and .md5 file)

Apache Commons also distributes convenience binaries at =
https://www.apache.org/dist/commons/XXX/binaries. These convenience =
binaries must also be signed and checksummed.

For even more convenience, Apache Commons also publishes packages to =
Maven Central.  Maven Central policy =
<http://central.sonatype.org/pages/requirements.html> requires:
=E2=80=9CProjects with packaging other than pom have to supply JAR files =
that contain Javadoc and sources.=E2=80=9D
=E2=80=9CAll files deployed need to be signed with GPG/PGP and a .asc =
file containing the signature must be included for each file.=E2=80=9D
A pom file with=20
Correct Coordinates
Project Name, Description and URL
License Information
Developer Information
SCM Information=

--Apple-Mail=_417CFF55-39EB-4B92-8BA6-23EE830F27B5--