Hi all,
I'm new to this discussion but I've been following along with the threads here.
If we can do multiple releases for the same project and version, then perhaps
we could use a multimodule project structure to help with the release process.
Here is what I'm picturing:
* Convert the project to have the following structure:
* commons-crypto-parent - parent pom for the project
* commons-crypto - all Java code for the project; does not explicitly
depend on commons-crypto-native (except for unit tests) but uses the classpath
resources from it if available
* commons-crypto-native - module containing prebuilt binaries for use
by commons-crypto; the artifact for the project is a jar with a classifier set
to the JNA name (os + arch) of the platform the binary is intended for.
* Perform the release in 2 stages: a primary/main release, and a prebuilt
binary release.
* The primary/main release consists of the source code along with
commons-crypto-parent and commons-crypto artifacts. The commons-crypto jar
would provide a fully-functional Java implementation but would need to be
combined with one of the commons-crypto-native artifacts or a binary provided
by the user in order to enable native functionality.
* The prebuilt binary release would consist of commons-crypto-native
artifacts for however many platforms we wish to provide binaries for. Each of
these artifacts would be distinguished by the artifact classifier. We could do
releases for these one at a time (worst case) or group a bunch of artifacts
built on different machines (best case).
* Users would use the library by adding dependencies on commons-crypto
along with commons-crypto-native for whatever platforms they need.
I've used this approach on several projects in my day job and it's worked out
pretty well. A couple benefits of this approach are that the release process is
easier when building for multiple platforms and the jars that users pull are
smaller (since they only need to contain the binaries that the user is actually
interested in).
Thoughts?
Regards,
Matt Juntunen
________________________________
From: Matt Sicker <boa...@gmail.com>
Sent: Sunday, August 9, 2020 11:58 AM
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [crypto] Releasing 1.1.0 with Mac64 support
Can convenience binaries be voted on separately from the regular
source release? If so, it might be easier to get the source out first
along with release binaries as they're created.
On Sun, 9 Aug 2020 at 06:13, sebb <seb...@gmail.com> wrote:
>
> It occurs to me that we don't *have* to release binaries.
>
> We could just release the source, as is done by several other ASF
> projects (including httpd).
>
> Sebb.
>
> On Mon, 3 Aug 2020 at 15:15, Geoffrey Blake <geoffrey.w.bl...@gmail.com>
> wrote:
> >
> > Hi Gary, has a solution for the Mac build been reached? Do you
> > require some assistance here? As Bindul suggested, Travis has support
> > for uploading artifacts to AWS S3:
> >
> > https://docs.travis-ci.com/user/uploading-artifacts/
> >
> > This may alleviate the issue with accepting an unknown artifact, and
> > with Travis, you have more confidence the artifact not only built but
> > passed unit-tests as well.
> >
> > -Geoff
> >
> > On Mon, Jul 27, 2020 at 2:26 PM Bindul Bhowmik <bindulbhow...@gmail.com>
> > wrote:
> > >
> > > Hi Gary,
> > >
> > > (Please ignore if it has been discussed already)
> > >
> > > On Mon, Jul 27, 2020 at 12:07 PM Gary Gregory <garydgreg...@gmail.com>
> > > wrote:
> > > >
> > > > Hi All,
> > > >
> > > > Thanks to Geoffrey Blake's help setting up a Docker Ubuntu Trusty
> > > > (14.04)
> > > > environment, I am working toward creating an RC for 1.1.0, but in order
> > > > to
> > > > get Mac64 support we are quite sure I need to build that binary on a
> > > > Mac,
> > > > which I do not own or have simple access to.
> > > >
> > > > Is there an acceptable workflow for me, the Release Manager, to procure
> > > > said binary from another person? Does that person need to be on the
> > > > Commons
> > > > PMC, a Commons Committer, an Apache Commons, an Apache Member, or can
> > > > it be
> > > > Anyone?
> > > >
> > > > There is an obvious trust issue here since I would not be the one
> > > > building
> > > > the Mac64 binary but would be delivering it through our dist area and
> > > > Maven
> > > > Central.
> > >
> > > commons-crypto is built on OSX on travis. So, a thought on getting the
> > > binaries out of that:
> > > If you had a place for travis to upload the artifacts: you could fork
> > > the repo, alter the .travis.yml to add a deployment step to upload the
> > > built OSX binaries to your location. I think this gets you, the
> > > release manager, a known good binary. You can add whatever 'on'
> > > conditions for the deploy to only upload binaries from the tag, etc. I
> > > am suggesting forking the repo, so the altered .travis.yml is not in
> > > the release source tag and the secrets to upload the binary are only
> > > in your github/travis org.
> > >
> > > >
> > > > Yes, I know that in theory, Apache only delivers source code and that
> > > > our
> > > > binary distributions are only a convenience, so there might be nothing
> > > > to
> > > > talk about, still, I want to make sure to check on expectations and
> > > > processes.
> > > >
> > > > Gary
> > >
> > > Bindul
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
--
Matt Sicker <boa...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
