Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
In-Reply-To: <CAOGo0Vb0NinopsA9csqe3EEoSu4D6nCYrh9tHcAC5tMNxweiKQ@mail.gmail.com>
References: <B957EE1AFDEBFD4B934BCF11804A23DC0489032F@shsmsx102.ccr.corp.intel.com>
 <B957EE1AFDEBFD4B934BCF11804A23DC0489037C@shsmsx102.ccr.corp.intel.com>
 <B957EE1AFDEBFD4B934BCF11804A23DC048DCC3C@shsmsx102.ccr.corp.intel.com>
 <CAOGo0VYvN-JpmSnWFGLtG4qiLJWfuEVXb=Zow4Kw=4Om0egxkQ@mail.gmail.com>
 <CAOGo0VaAEAPT63-woFxpH_9=YgTvA9acaJk-SQGj6T1MWC7B6A@mail.gmail.com>
 <B957EE1AFDEBFD4B934BCF11804A23DC048E1B76@shsmsx102.ccr.corp.intel.com>
 <CAOGo0VaZq1Um2Fv0t+=bYKzVjyN8ghBs_Gd6UdwFYVboD1KB0w@mail.gmail.com>
 <B957EE1AFDEBFD4B934BCF11804A23DC048EFAB9@shsmsx102.ccr.corp.intel.com>
 <CACZkXPwvVfmK+UTFE0u2S5crqTCvX_dcOzq4Y+mTyH+7EELucw@mail.gmail.com>
 <CAAOnQ7uCfmGQPSPJRGPf=UKEdDjngvSrBui=OY0DYsD54r5UeQ@mail.gmail.com>
 <CACZkXPy51zwE=UJK6pMz-=RevyOOcSupxF4etQSgJGG-HrBRgQ@mail.gmail.com> <CAOGo0Vb0NinopsA9csqe3EEoSu4D6nCYrh9tHcAC5tMNxweiKQ@mail.gmail.com>
From: "Bhowmik, Bindul" <bindulbhowmik@gmail.com>
Date: Fri, 8 Jul 2016 11:46:13 -0600
Message-ID: <CA+G35O2fkVpGZovyc9m=C7_pYGzZNAQHTFG2qP=zwQ8Ad98VQA@mail.gmail.com>
Subject: Re: [CRYPTO]1.0.0 Release Plan
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Fri, 08 Jul 2016 17:47:05 -0000

On Fri, Jul 8, 2016 at 11:37 AM, sebb <sebbaz@gmail.com> wrote:
> On 8 July 2016 at 18:31, Gary Gregory <garydgregory@gmail.com> wrote:
>> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin <vanzin@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 <garydgregory@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>

- Bindul

[1] http://download.eclipse.org/eclipse/downloads/drops4/R-4.6-201606061100/#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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org