commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Honton <c...@honton.org>
Subject Re: [ALL] Changing the commons process
Date Sat, 24 Dec 2016 00:02:40 GMT

I am incorrect about the contents of the sources zip.   It does contain all the files under
source control.

As a test, I replaced ~/.m2/repository/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5-src.jar
with the distribution commons-lang3-3.5-src.zip.  Using the eclipse IDE, I navigated from
the use of StringUtils.join() to its source.

I will test IntelliJ soon.  Are there any other IDEs that should be tested?  



> On Dec 23, 2016, at 2:54 PM, Bernd Eckenfels <ecki@zusammenkunft.net> wrote:
> 
> Hello,
> I think hybrid -sry/source does not work very well, since the IDE expect a package-like
directory structure. I am not sure it would work with src/main/ prefix.
> 
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> 
> On Fri, Dec 23, 2016 at 11:33 PM +0100, "Gary Gregory" <garydgregory@gmail.com>
wrote:
> 
> On Fri, Dec 23, 2016 at 12:54 PM, Charles Honton  wrote:
> 
>> Several recent email threads have discussed our parent pom and release
>> process.  The process we have derive from Apache Common’s rich history
>> which pre-dates many current distribution practices.  I’d 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?
> 
> 
> You cannot build from the -source jars so that would not work. We could ADD
> stuff to these jars to make them the same as the -src.zip files. Then we do
> not need the -src.zip/tar.gz files.
> 
> 
> 
>> 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.
>> 
> 
> Since the binaries are conveniences, we can do whatever we want IMO.
> 
> 
>> 
>> 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  release-contain> and Release Signing Policy  release-distribution.html#sigs-and-sums>
require:
>> “Every 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”
>> "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.” (.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  pages/requirements.html> requires:
>> “Projects with packaging other than pom have to supply JAR files that
>> contain Javadoc and sources.”
>> “All files deployed need to be signed with GPG/PGP and a .asc file
>> containing the signature must be included for each file.”
>> A pom file with
>> Correct Coordinates
>> Project Name, Description and URL
>> License Information
>> Developer Information
>> SCM Information
> 
> 
> A lighter weight system would:
> 
> - Publish the same as we do now to Maven Central PLUS adding all of the
> files needed to build to *-sources.jar files such that they become the same
> as *-src.zip/*-src.tar.gz files.
> - Publish the *-sources jar file to https://www.apache.org/dist/
> commons/XXX/source instead of the *-src.zip/*-src.tar.gz files.
> - Stop publishing *-bin files
> 
> The question is, if we publish a build-able *-source.jar file to
> https://repository.apache.org/content/repositories/releases/org/apache/commons/,
> why do we need to double that up and ALSO publish to
> https://www.apache.org/dist/commons/XXX/source ?
> 
> Not publishing to https://www.apache.org/dist/commons/
> would really simplify
> things.
> 
> Gary


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message