On 13 July 2016 at 07:04, Sun, Dapeng <dapeng....@intel.com> wrote: > Copy the native files from other platforms to target is worked. I also > uploaded a SNAPSHOT version contains native of Linux and Mac. If there is no > concerns, I will try to add windows and kick off the first release. > > https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.0.0-SNAPSHOT/commons-crypto-1.0.0-20160713.032556-2.jar >
That works for me on MacOSX (tested using 'java -jar commons-crypto-1.0.0-20160713.032556-2.jar') I think there need to be a RELEASE NOTES file (generated from the changes). I have created an initial sample; changes.xml needs to be updated with the OS/version support details and the RN regenerated. However I wonder whether the Changes section should be present, given that there is no previous release (AFAIK). If it is needed, then it needs updating with all the other relevant fixes. > Regards > Dapeng > > -----Original Message----- > From: sebb [mailto:seb...@gmail.com] > Sent: Wednesday, July 13, 2016 12:09 AM > To: Commons Developers List > Subject: Re: [CRYPTO]1.0.0 Release Plan > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
