On 11 July 2016 at 09:02, Sun, Dapeng <dapeng....@intel.com> wrote: > About the native binaries, I think we should put them in the same jar > finally. CRYPTO is library, user shouldn't need to specify Platform in > theory. I just checked the jars of JNA and SNAPPY at maven, the jar contains > native for all the platform their support. For the first release of CRYPTO, I > think we'd better to add Linux_x86, Linux_x86_64 and MAC_x86_64 at least.
Also Windows, now that it is working OK. 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. Maybe try creating a snapshot release with just Linux and Mac and see how that pans out. > About eclipse, I think it is different from CRYPTO, each eclipse's binary > file is platform specify and the binary file is not in small size... > > Regards > Dapeng > > -----Original Message----- > From: sebb [mailto:seb...@gmail.com] > Sent: Saturday, July 09, 2016 2:19 AM > To: Commons Developers List > Subject: Re: [CRYPTO]1.0.0 Release Plan > > On 8 July 2016 at 18:56, Gary Gregory <garydgreg...@gmail.com> wrote: >> On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul >> <bindulbhow...@gmail.com> >> wrote: >> >>> On Fri, Jul 8, 2016 at 11:37 AM, sebb <seb...@gmail.com> wrote: >>> > On 8 July 2016 at 18:31, Gary Gregory <garydgreg...@gmail.com> wrote: >>> >> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin >>> >> <van...@cloudera.com> >>> wrote: >>> >> >>> >>> Answering based on old knowledge of this code, but I don't >>> >>> believe it has changed... >>> >>> >>> >>> On Fri, Jul 8, 2016 at 9:36 AM, Gary Gregory >>> >>> <garydgreg...@gmail.com> >>> >>> wrote: >>> >>> > The delivered jar file contains a native .so file, and this .so >>> >>> > file >>> is >>> >>> > _extracted_ and _installed_ on the user's machine at runtime? >>> >>> > See NativeCodeLoader.extractLibraryFile(). >>> >>> >>> >>> It's not really installed, but copied to a temp location. There >>> >>> might be flags to configure a permanent location (which would >>> >>> bypass this code that finds the library inside the jar), but I >>> >>> don't remember if that was added to crypto. >>> >>> >>> >>> This feature is borrowed from Snappy's java bindings, and is >>> >>> pretty helpful on distributed applications where a "launcher" app >>> >>> starts processes on a whole bunch of different machines (and >>> >>> needs these libraries). >>> >>> >>> >>> > Does this mean that the jar will contain all possible native >>> >>> > formats >>> >>> (.so, >>> >>> > .dll, what about 32 vs. 64 bit, or are we only dealing with 64 >>> >>> > bit?) >>> and >>> >>> > extract the right one at runtime for the current platform? >>> >>> > Seems >>> wasteful >>> >>> > in space but portable and clever. >>> >>> One option could be to go the Eclipse way, the way they handle SWT >>> distributions which have native components[1]. Thinking more about >>> it, that might even be a better option given that the different >>> binary components may need to be built on different OSes. >>> >>> And from a consumption standpoint, if the user is using Maven, they >>> could use profiles to select the correct dependency. I have done >>> something like this for SWT on a project: >>> >>> <dependency> >>> <groupId>org.eclipse.swt</groupId> >>> <artifactId>${swt.artifact}</artifactId> >>> <version>${eclipse.swt.version}</version> >>> <scope>compile</scope> >>> </dependency> >>> >>> <profile> >>> <id>win64_x8664</id> >>> <activation> >>> <os> >>> <family>windows</family> >>> <arch>x86_64</arch> >>> </os> >>> </activation> >>> <properties> >>> <swt.artifact>swt-win32-win32-x86_64</swt.artifact> >>> </properties> >>> </profile> >>> <profile> >>> <id>linux64_x8664</id> >>> <activation> >>> <os> >>> <family>unix</family> >>> <arch>x86_64</arch> >>> </os> >>> </activation> >>> <properties> >>> <swt.artifact>swt-gtk-linux-x86_64</swt.artifact> >>> </properties> >>> </profile> >>> >>> >> Yeah, that seems like a more normal way to go. >> >> We've been making changes for 1.0 for a little while now (not _that_ >> long) but this would be a big change because the Maven coordinate business. >> >> Let's see what the rest if the community thinks. >> >> I am concerned as I've already stated as to what the current scheme >> means went Windows DLL support is done. It does not seem OK to include >> >1 native library in the jar. > > Another possibility for the first release is to avoid the problem entirely, > by only releasing source. > > AIUI many Linux distros rebuild from source anyway. > > We would need to ensure that the build instructions are clear, and that the > code produced a sensible error message if the JNI code is not found. > This could include a URL to the latest build instructions/FAQ (like Maven > does). > > But longer term it might be better to release the JNI binaries separately > from the Java binaries. > This would allow new OSes to be added without having to re-release everything. > >> Gary >> >> >>> - Bindul >>> >>> [1] >>> http://download.eclipse.org/eclipse/downloads/drops4/R-4.6-2016060611 >>> 00/#SWT >>> >>> >>> >>> >>> That's the goal if multiple OSes are to be supported; I'm not >>> >>> sure how easy it would be to achieve with the current build >>> >>> system available (haven't really looked into it), but I have >>> >>> ideas of how to hack something like that in maven (using a few >>> >>> separate jobs per OS + a final job to collect everything). >>> >>> >>> >>> I've heard comments here about using JNA, so maybe this whole >>> >>> discussion will eventually become moot? >>> >>> >>> >> >>> >> The JNA code is in place, it's just much slower than the JNI path. >>> > >>> > Have you managed to get it going on Windows? >>> > >>> > So far I have failed. >>> > It's tricky getting JNA to find the crypto DLL, and then it hangs >>> > for me on the ERR_load_crypto_strings() call. >>> > [Or it is so slow that it seems like it is hanging] >>> > >>> > I was able to get SSLeay_version(int type) working in a simple app >>> > that does not do the ERR_load call. >>> > But if I leave out the ERR_load from OpenSslNativeJna.java the >>> > tests >>> still hang. >>> > >>> >> Gary >>> >> >>> >> >>> >>> >>> >>> -- >>> >>> Marcelo >>> >>> >>> >>> ----------------------------------------------------------------- >>> >>> ---- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >>> >>> >> >>> >> >>> >> -- >>> >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java >>> >> Persistence with Hibernate, Second Edition >>> >> <http://www.manning.com/bauer3/> JUnit in Action, Second Edition >>> >> <http://www.manning.com/tahchiev/> >>> >> Spring Batch in Action <http://www.manning.com/templier/> >>> >> Blog: http://garygregory.wordpress.com >>> >> Home: http://garygregory.com/ >>> >> Tweet! http://twitter.com/GaryGregory >>> > >>> > ------------------------------------------------------------------- >>> > -- 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 >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence >> with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit >> in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory > > --------------------------------------------------------------------- > 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
