On 12 July 2016 at 14:20, Sun, Dapeng <dapeng....@intel.com> wrote: > Separating artifacts for each native library, I think it should be same as > copying the native binary files. We also need to collect the artifacts for > unpacking and bundling.
Yes. > About using the 'all' artifact, users may be confused about downloading the > artifacts for all the different platforms, especially for the platforms they > don't need. I think we could have a separate project that creates a jar containing the Java classes plus all released native builds. AIUI the code can automatically extract the native code from the jar, so it should be easy to use. If we also release the Java classes and native builds as separate jars, then users would have the choice: - download the jar containing the Java classes plus all released native builds - download the Java classes jar plus any native builds they need Or maybe when releasing a native build, we could package it with the Java classes. That would give users a different choice: - download the specific build for their system; this would work as is - download the combined build for all released native targets > -----Original Message----- > From: Marcelo Vanzin [mailto:van...@cloudera.com] > Sent: Tuesday, July 12, 2016 2:09 AM > To: Commons Developers List <dev@commons.apache.org> > Subject: Re: [CRYPTO]1.0.0 Release Plan > > On Mon, Jul 11, 2016 at 2:34 AM, sebb <seb...@gmail.com> wrote: >> However bundling multiple native binaries is going to make it tricky to >> release. >> How will it be done? The native parts will have to be built separately >> and then combined somehow. > > The way I'd do it is to have separate artifacts for each native library, and > then a final job that merges all those into a final "commons-crypto-all" > artifact containing all the native libraries. > That would mean a single artifact ultimately deployed as part of a > commons-crypto release, but I don't know how easy it is to pull that off as > far as build infrastructure goes. > > Another option is to actually deploy each native artifact separately, and > have the "all" artifact be just a dummy artifact that depends on all the > others; so no jar merging or anything. That might be easier. > Maybe. > > -- > Marcelo > > --------------------------------------------------------------------- > 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
