commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [ALL] Changing the commons process
Date Sat, 24 Dec 2016 00:07:05 GMT
On Fri, Dec 23, 2016 at 4:02 PM, Charles Honton <chas@honton.org> wrote:

>
> 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?
>

NetBeans?

G


>
>
>
> > 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
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

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