On 12 July 2016 at 14:54, sebb <seb...@gmail.com> wrote: > 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.
It looks like that already happens - the MacOSX installed jar includes the jnilib file. > 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
