I would think we would want a release paradigm that is as similar to as many other projects as possible, for the sake of intuitive navigation of the project from the consumer perspective.
Might we look at some other large (Apache v. non-Apache and java v. non-java) projects to see how we stack up relative to them with our release artifacts? -Rob > On Dec 23, 2016, at 5:54 PM, Bernd Eckenfels <e...@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" > <garydgreg...@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 > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > > > > JUnit in Action, Second Edition > > > > Spring Batch in Action > > > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
