You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by "Sun, Dapeng" <da...@intel.com> on 2016/06/06 09:13:35 UTC

[CRYPTO]1.0.0 Release Plan

Hello,

Apache Commons CRYPTO was established at May 9, 2016[1], There are presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also fixed the legal issue[3].

With the first release, we can begin to promote CRYPTO to other Apache components, like Apache Hadoop, Apache Spark, so that they can benefit the higher performance improvement from Apache Commons Crypto.

We plan the following three opening features to next release(I think it should be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark tool[6]. Please let me know if there is anything need to be done before the release.


Regards
Dapeng


[1] http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E
[2] http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
[3] http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com%3E
[4] https://github.com/apache/commons-crypto/pull/44
[5] https://github.com/apache/commons-crypto/pull/47
[6] https://github.com/apache/commons-crypto/pull/1

Re: [CRYPTO]1.0.0 Release Plan

Posted by sebb <se...@gmail.com>.

On 8 July 2016 at 18:37, sebb <se...@gmail.com> wrote:
> On 8 July 2016 at 18:31, Gary Gregory <ga...@gmail.com> wrote:
>> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin <va...@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 <ga...@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.
>>>
>>> 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 now works using MinGW to build the JNI library and a more recent OpenSSL DLL.

> 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.

The JNA code now works fine on Windows.
I think the problem earlier was that the wrong DLL was being loaded.
This should not cause a hang - that needs to be investigated.

>> 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

Re: [CRYPTO]1.0.0 Release Plan

Posted by Gary Gregory <ga...@gmail.com>.

On Fri, Jul 8, 2016 at 10:37 AM, sebb <se...@gmail.com> wrote:

> On 8 July 2016 at 18:31, Gary Gregory <ga...@gmail.com> wrote:
> > On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin <va...@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 <ga...@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.
> >>
> >> 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?
>

I have only tried running the unit tests which are either green or skipped.

I am OK if we say we do not support Windows for 1.0.

I am just concerned that we get the public API right to allow for both JNI
and JNA, which should all be under the covers and hidden to the API user
anyway.

Gary


>
> 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
>
>


-- 
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

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Sun, Dapeng" <da...@intel.com>.

I think we can copy the native binary files complied by different platforms, and put them into target folder. Then all the native files would be packaged into one jar.

Okay, I will build a SNAPSHOT contains Linux and Mac.

Regards
Dapeng


-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com] 
Sent: Monday, July 11, 2016 5:35 PM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [CRYPTO]1.0.0 Release Plan

On 11 July 2016 at 09:02, Sun, Dapeng <da...@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:sebbaz@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 <ga...@gmail.com> wrote:
>> On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul 
>> <bi...@gmail.com>
>> wrote:
>>
>>> On Fri, Jul 8, 2016 at 11:37 AM, sebb <se...@gmail.com> wrote:
>>> > On 8 July 2016 at 18:31, Gary Gregory <ga...@gmail.com> wrote:
>>> >> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin 
>>> >> <va...@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 
>>> >>> <ga...@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-201606061
>>> 1
>>> 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-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
>>>
>>>
>>
>>
>> --
>> 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

Re: [CRYPTO]1.0.0 Release Plan

Posted by Gary Gregory <ga...@gmail.com>.

On Mon, Jul 11, 2016 at 11:08 AM, Marcelo Vanzin <va...@cloudera.com>
wrote:

> On Mon, Jul 11, 2016 at 2:34 AM, sebb <se...@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.
>

It does not need to be a dummy as much as a BOM. We do this in Log4j 2.

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

Re: [CRYPTO]1.0.0 Release Plan

Posted by sebb <se...@gmail.com>.

On 13 July 2016 at 07:04, Sun, Dapeng <da...@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:sebbaz@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 <se...@gmail.com> wrote:
>> On 12 July 2016 at 14:20, Sun, Dapeng <da...@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:vanzin@cloudera.com]
>>> Sent: Tuesday, July 12, 2016 2:09 AM
>>> To: Commons Developers List <de...@commons.apache.org>
>>> Subject: Re: [CRYPTO]1.0.0 Release Plan
>>>
>>> On Mon, Jul 11, 2016 at 2:34 AM, sebb <se...@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-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
>

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

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Sun, Dapeng" <da...@intel.com>.

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


Regards
Dapeng

-----Original Message-----
From: sebb [mailto:sebbaz@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 <se...@gmail.com> wrote:
> On 12 July 2016 at 14:20, Sun, Dapeng <da...@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:vanzin@cloudera.com]
>> Sent: Tuesday, July 12, 2016 2:09 AM
>> To: Commons Developers List <de...@commons.apache.org>
>> Subject: Re: [CRYPTO]1.0.0 Release Plan
>>
>> On Mon, Jul 11, 2016 at 2:34 AM, sebb <se...@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-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

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Sun, Dapeng" <da...@intel.com>.

Hi all,

I want to kick off the process of the first release on July 25th (next Monday) , please let me know if you have any concerns.

And here is the latest binary.(contains Linux/Mac/Windows)
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.0.0-SNAPSHOT/commons-crypto-1.0.0-20160722.085755-6.jar

Thanks & Regards
Dapeng

-----Original Message-----
From: Sun, Dapeng [mailto:dapeng.sun@intel.com] 
Sent: Tuesday, July 19, 2016 6:48 PM
To: Commons Developers List
Subject: RE: [CRYPTO]1.0.0 Release Plan

Thank Dennis for your suggestion, but it seems maven and apache site don't provide the feature. And the native files are all small size, putting them into one jar would be okay.

Regards
Dapeng

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Thursday, July 14, 2016 11:18 PM
To: 'Commons Developers List'
Subject: RE: [CRYPTO]1.0.0 Release Plan

I don't know if the deployment method for the binaries (.jar, etc.) of these releases provides useful download statistics for the Commons project.

If it does, differentiating by the native platforms for which there are native shared-libraries that need to also be on the runtime path (e.g., to work with JNI) is important.  You will have some evidence for what your users intend to run the related classes on.

That might be important to know if you are considering a triage with respect to native support.

 - Dennis

> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Tuesday, July 12, 2016 09:09
> To: Commons Developers List <de...@commons.apache.org>
> Subject: Re: [CRYPTO]1.0.0 Release Plan
> 
> On 12 July 2016 at 14:54, sebb <se...@gmail.com> wrote:
> > On 12 July 2016 at 14:20, Sun, Dapeng <da...@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.
> 
[ .... ]


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

B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB  [  X  ܚX KK[XZ[
 ] ][  X  ܚX P  [[ۜ˘\X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 ] Z[  [[ۜ˘\X K ܙ B

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Sun, Dapeng" <da...@intel.com>.

Thank Dennis for your suggestion, but it seems maven and apache site don't provide the feature. And the native files are all small size, putting them into one jar would be okay.

Regards
Dapeng

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Thursday, July 14, 2016 11:18 PM
To: 'Commons Developers List'
Subject: RE: [CRYPTO]1.0.0 Release Plan

I don't know if the deployment method for the binaries (.jar, etc.) of these releases provides useful download statistics for the Commons project.

If it does, differentiating by the native platforms for which there are native shared-libraries that need to also be on the runtime path (e.g., to work with JNI) is important.  You will have some evidence for what your users intend to run the related classes on.

That might be important to know if you are considering a triage with respect to native support.

 - Dennis

> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Tuesday, July 12, 2016 09:09
> To: Commons Developers List <de...@commons.apache.org>
> Subject: Re: [CRYPTO]1.0.0 Release Plan
> 
> On 12 July 2016 at 14:54, sebb <se...@gmail.com> wrote:
> > On 12 July 2016 at 14:20, Sun, Dapeng <da...@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.
> 
[ .... ]


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

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Dennis E. Hamilton" <de...@acm.org>.

I don't know if the deployment method for the binaries (.jar, etc.) of these releases provides useful download statistics for the Commons project.

If it does, differentiating by the native platforms for which there are native shared-libraries that need to also be on the runtime path (e.g., to work with JNI) is important.  You will have some evidence for what your users intend to run the related classes on.

That might be important to know if you are considering a triage with respect to native support.

 - Dennis

> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Tuesday, July 12, 2016 09:09
> To: Commons Developers List <de...@commons.apache.org>
> Subject: Re: [CRYPTO]1.0.0 Release Plan
> 
> On 12 July 2016 at 14:54, sebb <se...@gmail.com> wrote:
> > On 12 July 2016 at 14:20, Sun, Dapeng <da...@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.
> 
[ .... ]


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

Re: [CRYPTO]1.0.0 Release Plan

Posted by sebb <se...@gmail.com>.

On 12 July 2016 at 14:54, sebb <se...@gmail.com> wrote:
> On 12 July 2016 at 14:20, Sun, Dapeng <da...@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:vanzin@cloudera.com]
>> Sent: Tuesday, July 12, 2016 2:09 AM
>> To: Commons Developers List <de...@commons.apache.org>
>> Subject: Re: [CRYPTO]1.0.0 Release Plan
>>
>> On Mon, Jul 11, 2016 at 2:34 AM, sebb <se...@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-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

Re: [CRYPTO]1.0.0 Release Plan

Posted by sebb <se...@gmail.com>.

On 12 July 2016 at 14:20, Sun, Dapeng <da...@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:vanzin@cloudera.com]
> Sent: Tuesday, July 12, 2016 2:09 AM
> To: Commons Developers List <de...@commons.apache.org>
> Subject: Re: [CRYPTO]1.0.0 Release Plan
>
> On Mon, Jul 11, 2016 at 2:34 AM, sebb <se...@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-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

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Sun, Dapeng" <da...@intel.com>.

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.

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.

-----Original Message-----
From: Marcelo Vanzin [mailto:vanzin@cloudera.com] 
Sent: Tuesday, July 12, 2016 2:09 AM
To: Commons Developers List <de...@commons.apache.org>
Subject: Re: [CRYPTO]1.0.0 Release Plan

On Mon, Jul 11, 2016 at 2:34 AM, sebb <se...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [CRYPTO]1.0.0 Release Plan

Posted by Marcelo Vanzin <va...@cloudera.com>.

On Mon, Jul 11, 2016 at 2:34 AM, sebb <se...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [CRYPTO]1.0.0 Release Plan

Posted by sebb <se...@gmail.com>.

On 11 July 2016 at 09:02, Sun, Dapeng <da...@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:sebbaz@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 <ga...@gmail.com> wrote:
>> On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul
>> <bi...@gmail.com>
>> wrote:
>>
>>> On Fri, Jul 8, 2016 at 11:37 AM, sebb <se...@gmail.com> wrote:
>>> > On 8 July 2016 at 18:31, Gary Gregory <ga...@gmail.com> wrote:
>>> >> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin
>>> >> <va...@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
>>> >>> <ga...@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-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
>>>
>>>
>>
>>
>> --
>> 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

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Sun, Dapeng" <da...@intel.com>.

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.

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:sebbaz@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 <ga...@gmail.com> wrote:
> On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul 
> <bi...@gmail.com>
> wrote:
>
>> On Fri, Jul 8, 2016 at 11:37 AM, sebb <se...@gmail.com> wrote:
>> > On 8 July 2016 at 18:31, Gary Gregory <ga...@gmail.com> wrote:
>> >> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin 
>> >> <va...@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 
>> >>> <ga...@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-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
>>
>>
>
>
> --
> 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

Re: [CRYPTO]1.0.0 Release Plan

Posted by sebb <se...@gmail.com>.

On 8 July 2016 at 18:56, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul <bi...@gmail.com>
> wrote:
>
>> On Fri, Jul 8, 2016 at 11:37 AM, sebb <se...@gmail.com> wrote:
>> > On 8 July 2016 at 18:31, Gary Gregory <ga...@gmail.com> wrote:
>> >> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin <va...@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 <ga...@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-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
>>
>>
>
>
> --
> 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

Re: [CRYPTO]1.0.0 Release Plan

Posted by Marcelo Vanzin <va...@cloudera.com>.

On Fri, Jul 8, 2016 at 10:56 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul <bi...@gmail.com>
> wrote:
>> One option could be to go the Eclipse way, the way they handle SWT
>> distributions which have native components[1].
>>
> Yeah, that seems like a more normal way to go.

It's fine to break down native libraries into separate artifacts, as
long as there's no restriction around which native libraries can be
included in an application. i.e. you'd have a single artifact for the
java code, and one each for each native library.

That's needed to support applications that need to run on
heterogeneous environments; imagine a distributed app where the
launcher is on Windows or MacOS but workers are running on Linux. You
still want people to be able to build the application once and deploy
it, instead of having to build it for every separate target OS and
figure out at runtime which version to run.

(All this is a long winded way to say: I wouldn't use those profiles
when building applications using crypto. Instead, I'd package all
native libraries I think are useful for my application, and rely on
the code to figure out which one to use at runtime.)

-- 
Marcelo

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

Re: [CRYPTO]1.0.0 Release Plan

Posted by Jörg Schaible <jo...@gmx.de>.

sebb wrote:

[snip]

> 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.

This one might help: http://maven-nar.github.io/

I've used a very old version of it several years ago for such a scenario.

Cheers,
J�rg


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

Re: [CRYPTO]1.0.0 Release Plan

Posted by Gary Gregory <ga...@gmail.com>.

On Fri, Jul 8, 2016 at 10:46 AM, Bhowmik, Bindul <bi...@gmail.com>
wrote:

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

Gary


> - 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
>
>


-- 
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

Re: [CRYPTO]1.0.0 Release Plan

Posted by "Bhowmik, Bindul" <bi...@gmail.com>.

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

Re: [CRYPTO]1.0.0 Release Plan

Posted by sebb <se...@gmail.com>.

On 8 July 2016 at 18:31, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin <va...@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 <ga...@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.
>>
>> 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

Re: [CRYPTO]1.0.0 Release Plan

Posted by Gary Gregory <ga...@gmail.com>.

On Fri, Jul 8, 2016 at 10:07 AM, Marcelo Vanzin <va...@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 <ga...@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.
>
> 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.

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

Re: [CRYPTO]1.0.0 Release Plan

Posted by Marcelo Vanzin <va...@cloudera.com>.

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 <ga...@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.

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?

-- 
Marcelo

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

Re: [CRYPTO]1.0.0 Release Plan

Posted by Gary Gregory <ga...@gmail.com>.

Hi All,

This might be OK for 1.0 (with no Windows support) but I want to make sure
we are all on the same page because it seems incredibly complicated and
perhaps too clever.

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().

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.

Or, will there be a jar built with an .so file in it and a different jar
built with a .dll in it (and 32 vs. 64 bit)?

Depending on the choice, we need different maven coordinates to accommodate
all the jar-file-contains-a-single-native-file combinations.

In Commons-Deamon we also deliver native files, not embedded in jar files,
but on the side.

Gary

On Thu, Jul 7, 2016 at 10:51 PM, Sun, Dapeng <da...@intel.com> wrote:

> Hi all,
>
> Please let me know if there is any blocks need to be resolved before the
> release.
>
> Regards
> Dapeng
>
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Tuesday, June 28, 2016 6:48 PM
> To: Commons Developers List
> Subject: Re: [CRYPTO]1.0.0 Release Plan
>
> On 28 June 2016 at 07:03, Sun, Dapeng <da...@intel.com> wrote:
> > Thank Sebb for your great work!
> >
> > About the Properties instance, I have some personal opinions.
> >
> > I think properties provide a flexible configuration mechanism. Config
> values could be added and read/written without too much limitation, we also
> provides default values for each properties, user don't need set value for
> every properties. They could also give null, if they want to use the
> default settings.
>
> Agreed they are flexible.
>
> >>> also the way that classes are instantiated is very awkward, as
> properties are not as easy to use as plain variables - String/boolean etc
> and properties don't offer any type validation.
> >
> > Properties don't offer any type validation, but we can validate the type
> and value before we using them. For example, stream buffer size, when
> CryptoStream is creating, it will read the value and convert it to int.
> >
> >>> Since properties are used in the constructors, it's not enough for 3rd
> parties to just implement the CryptoRandom interface - they also have to
> provide a constructor which takes a Properties instance.
> >
> > For 3rd parties implementations, they may need to read some
> configuration when initializing, properties will provide this ability at
> this time. Otherwise, they need to handle the work such as reading config
> file, read config value ant etc. For the 3rd parties implementations which
> don't need the properties, they can leave it null or ignore.
> >
> > If you have a better configuration mechanism, could you tell me more
> detail?
>
> On further reflection, I think it's not going to make the API any easier
> for the general case where implementation-specific values are needed.
>
> However, we could perhaps add a convenience method for the case where only
> the classname(s) are needed.
>  e.g. add  new methods as below:
>
> CryptoRandom getCryptoRandom(String classids) and CryptoCipher
> getInstance(String transformation, String classids)
>
> These would each create a Property instance and call the existing
> getInstance method
>
> This would not save a lot of code, but it would be simpler for the OpenSSL
> implementations at least.
>
> > Regards
> > Dapeng
> >
> > -----Original Message-----
> > From: sebb [mailto:sebbaz@gmail.com]
> > Sent: Sunday, June 26, 2016 7:53 AM
> > To: Commons Developers List
> > Subject: Re: [CRYPTO]1.0.0 Release Plan
> >
> > On 24 June 2016 at 11:17, sebb <se...@gmail.com> wrote:
> >> On 24 June 2016 at 10:08, Sun, Dapeng <da...@intel.com> wrote:
> >>> Hi all,
> >>>
> >>> Thank all for helping review CRYPTO from different angles.
> >>>
> >>> According the number of jira remaining issues, I prefer to start the
> thread for rolling a RC at June 29th(Next Wednesday). Please feel free to
> let me know if you have any concern about it.
> >>
> >> Yes, I do have some concerns.
> >>
> >> I think the public API needs to be better documented.
> >> There are still a lot of public classes that AFAICT don't really
> >> belong in the API.
> >> For example
> >> JceCipher
> >> OpensslCipher
> >> JavaCryptoRandom
> >> OpensslCryptoRandom
> >> OsCryptoRandom
> >> These need to be made private/package protected or moved into an
> >> internal package, or at the very least clearly documented as internal.
> >
> > I have made them package private.
> >
> >> Also the way that classes are instantiated is very awkward, as
> >> properties are not as easy to use as plain variables - String/boolean
> >> etc - and properties don't offer any type validation.
> >> Since properties are used in the constructors, it's not enough for
> >> 3rd parties to just implement the CryptoRandom interface - they also
> >> have to provide a constructor which takes a Properties instance.
> >
> > This is still an issue.
> >
> >> Indeed I wonder why there is a CryptoRandom interface - would it not
> >> be better for JavaCryptoRandom to extend java.util.Random? The other
> >> implementations of CryptoRandom do.
> >> Or maybe none of them should extend j.u.Random?
> >
> > Likewise, this ought to be resolved.
> >
> >>> Regards
> >>> Dapeng
> >>>
> >>> -----Original Message-----
> >>> From: Sun, Dapeng [mailto:dapeng.sun@intel.com]
> >>> Sent: Monday, June 06, 2016 5:14 PM
> >>> To: Commons Developers List
> >>> Subject: [CRYPTO]1.0.0 Release Plan
> >>>
> >>> Hello,
> >>>
> >>> Apache Commons CRYPTO was established at May 9, 2016[1], There are
> presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also
> fixed the legal issue[3].
> >>>
> >>> With the first release, we can begin to promote CRYPTO to other Apache
> components, like Apache Hadoop, Apache Spark, so that they can benefit the
> higher performance improvement from Apache Commons Crypto.
> >>>
> >>> We plan the following three opening features to next release(I think
> it should be 1.1.0): GCM support[4], JNACipher implementation[5] and
> benchmark tool[6]. Please let me know if there is anything need to be done
> before the release.
> >>>
> >>>
> >>> Regards
> >>> Dapeng
> >>>
> >>>
> >>> [1]
> >>> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3C
> >>> C
> >>> AB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.co
> >>> m
> >>> %3E [2]
> >>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&
> >>> p
> >>> id=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=
> >>> 6
> >>> [3]
> >>> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3C
> >>> C
> >>> ACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.
> >>> c om%3E [4] https://github.com/apache/commons-crypto/pull/44
> >>> [5] https://github.com/apache/commons-crypto/pull/47
> >>> [6] https://github.com/apache/commons-crypto/pull/1
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> - 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
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>


-- 
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

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Sun, Dapeng" <da...@intel.com>.

Hi all,

Please let me know if there is any blocks need to be resolved before the release.

Regards
Dapeng

-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com] 
Sent: Tuesday, June 28, 2016 6:48 PM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

On 28 June 2016 at 07:03, Sun, Dapeng <da...@intel.com> wrote:
> Thank Sebb for your great work!
>
> About the Properties instance, I have some personal opinions.
>
> I think properties provide a flexible configuration mechanism. Config values could be added and read/written without too much limitation, we also provides default values for each properties, user don't need set value for every properties. They could also give null, if they want to use the default settings.

Agreed they are flexible.

>>> also the way that classes are instantiated is very awkward, as properties are not as easy to use as plain variables - String/boolean etc and properties don't offer any type validation.
>
> Properties don't offer any type validation, but we can validate the type and value before we using them. For example, stream buffer size, when CryptoStream is creating, it will read the value and convert it to int.
>
>>> Since properties are used in the constructors, it's not enough for 3rd parties to just implement the CryptoRandom interface - they also have to provide a constructor which takes a Properties instance.
>
> For 3rd parties implementations, they may need to read some configuration when initializing, properties will provide this ability at this time. Otherwise, they need to handle the work such as reading config file, read config value ant etc. For the 3rd parties implementations which don't need the properties, they can leave it null or ignore.
>
> If you have a better configuration mechanism, could you tell me more detail?

On further reflection, I think it's not going to make the API any easier for the general case where implementation-specific values are needed.

However, we could perhaps add a convenience method for the case where only the classname(s) are needed.
 e.g. add  new methods as below:

CryptoRandom getCryptoRandom(String classids) and CryptoCipher getInstance(String transformation, String classids)

These would each create a Property instance and call the existing getInstance method

This would not save a lot of code, but it would be simpler for the OpenSSL implementations at least.

> Regards
> Dapeng
>
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Sunday, June 26, 2016 7:53 AM
> To: Commons Developers List
> Subject: Re: [CRYPTO]1.0.0 Release Plan
>
> On 24 June 2016 at 11:17, sebb <se...@gmail.com> wrote:
>> On 24 June 2016 at 10:08, Sun, Dapeng <da...@intel.com> wrote:
>>> Hi all,
>>>
>>> Thank all for helping review CRYPTO from different angles.
>>>
>>> According the number of jira remaining issues, I prefer to start the thread for rolling a RC at June 29th(Next Wednesday). Please feel free to let me know if you have any concern about it.
>>
>> Yes, I do have some concerns.
>>
>> I think the public API needs to be better documented.
>> There are still a lot of public classes that AFAICT don't really 
>> belong in the API.
>> For example
>> JceCipher
>> OpensslCipher
>> JavaCryptoRandom
>> OpensslCryptoRandom
>> OsCryptoRandom
>> These need to be made private/package protected or moved into an 
>> internal package, or at the very least clearly documented as internal.
>
> I have made them package private.
>
>> Also the way that classes are instantiated is very awkward, as 
>> properties are not as easy to use as plain variables - String/boolean 
>> etc - and properties don't offer any type validation.
>> Since properties are used in the constructors, it's not enough for 
>> 3rd parties to just implement the CryptoRandom interface - they also 
>> have to provide a constructor which takes a Properties instance.
>
> This is still an issue.
>
>> Indeed I wonder why there is a CryptoRandom interface - would it not 
>> be better for JavaCryptoRandom to extend java.util.Random? The other 
>> implementations of CryptoRandom do.
>> Or maybe none of them should extend j.u.Random?
>
> Likewise, this ought to be resolved.
>
>>> Regards
>>> Dapeng
>>>
>>> -----Original Message-----
>>> From: Sun, Dapeng [mailto:dapeng.sun@intel.com]
>>> Sent: Monday, June 06, 2016 5:14 PM
>>> To: Commons Developers List
>>> Subject: [CRYPTO]1.0.0 Release Plan
>>>
>>> Hello,
>>>
>>> Apache Commons CRYPTO was established at May 9, 2016[1], There are presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also fixed the legal issue[3].
>>>
>>> With the first release, we can begin to promote CRYPTO to other Apache components, like Apache Hadoop, Apache Spark, so that they can benefit the higher performance improvement from Apache Commons Crypto.
>>>
>>> We plan the following three opening features to next release(I think it should be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark tool[6]. Please let me know if there is anything need to be done before the release.
>>>
>>>
>>> Regards
>>> Dapeng
>>>
>>>
>>> [1]
>>> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3C
>>> C 
>>> AB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.co
>>> m
>>> %3E [2]
>>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&
>>> p
>>> id=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=
>>> 6
>>> [3]
>>> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3C
>>> C 
>>> ACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.
>>> c om%3E [4] https://github.com/apache/commons-crypto/pull/44
>>> [5] https://github.com/apache/commons-crypto/pull/47
>>> [6] https://github.com/apache/commons-crypto/pull/1
>>>
>>>
>>> --------------------------------------------------------------------
>>> - 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
>
>
> ---------------------------------------------------------------------
> 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

Re: [CRYPTO]1.0.0 Release Plan

Posted by sebb <se...@gmail.com>.

On 28 June 2016 at 07:03, Sun, Dapeng <da...@intel.com> wrote:
> Thank Sebb for your great work!
>
> About the Properties instance, I have some personal opinions.
>
> I think properties provide a flexible configuration mechanism. Config values could be added and read/written without too much limitation, we also provides default values for each properties, user don't need set value for every properties. They could also give null, if they want to use the default settings.

Agreed they are flexible.

>>> also the way that classes are instantiated is very awkward, as properties are not as easy to use as plain variables - String/boolean etc and properties don't offer any type validation.
>
> Properties don't offer any type validation, but we can validate the type and value before we using them. For example, stream buffer size, when CryptoStream is creating, it will read the value and convert it to int.
>
>>> Since properties are used in the constructors, it's not enough for 3rd parties to just implement the CryptoRandom interface - they also have to provide a constructor which takes a Properties instance.
>
> For 3rd parties implementations, they may need to read some configuration when initializing, properties will provide this ability at this time. Otherwise, they need to handle the work such as reading config file, read config value ant etc. For the 3rd parties implementations which don't need the properties, they can leave it null or ignore.
>
> If you have a better configuration mechanism, could you tell me more detail?

On further reflection, I think it's not going to make the API any
easier for the general case where implementation-specific values are
needed.

However, we could perhaps add a convenience method for the case where
only the classname(s) are needed.
 e.g. add  new methods as below:

CryptoRandom getCryptoRandom(String classids)
and
CryptoCipher getInstance(String transformation, String classids)

These would each create a Property instance and call the existing
getInstance method

This would not save a lot of code, but it would be simpler for the
OpenSSL implementations at least.

> Regards
> Dapeng
>
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Sunday, June 26, 2016 7:53 AM
> To: Commons Developers List
> Subject: Re: [CRYPTO]1.0.0 Release Plan
>
> On 24 June 2016 at 11:17, sebb <se...@gmail.com> wrote:
>> On 24 June 2016 at 10:08, Sun, Dapeng <da...@intel.com> wrote:
>>> Hi all,
>>>
>>> Thank all for helping review CRYPTO from different angles.
>>>
>>> According the number of jira remaining issues, I prefer to start the thread for rolling a RC at June 29th(Next Wednesday). Please feel free to let me know if you have any concern about it.
>>
>> Yes, I do have some concerns.
>>
>> I think the public API needs to be better documented.
>> There are still a lot of public classes that AFAICT don't really
>> belong in the API.
>> For example
>> JceCipher
>> OpensslCipher
>> JavaCryptoRandom
>> OpensslCryptoRandom
>> OsCryptoRandom
>> These need to be made private/package protected or moved into an
>> internal package, or at the very least clearly documented as internal.
>
> I have made them package private.
>
>> Also the way that classes are instantiated is very awkward, as
>> properties are not as easy to use as plain variables - String/boolean
>> etc - and properties don't offer any type validation.
>> Since properties are used in the constructors, it's not enough for 3rd
>> parties to just implement the CryptoRandom interface - they also have
>> to provide a constructor which takes a Properties instance.
>
> This is still an issue.
>
>> Indeed I wonder why there is a CryptoRandom interface - would it not
>> be better for JavaCryptoRandom to extend java.util.Random? The other
>> implementations of CryptoRandom do.
>> Or maybe none of them should extend j.u.Random?
>
> Likewise, this ought to be resolved.
>
>>> Regards
>>> Dapeng
>>>
>>> -----Original Message-----
>>> From: Sun, Dapeng [mailto:dapeng.sun@intel.com]
>>> Sent: Monday, June 06, 2016 5:14 PM
>>> To: Commons Developers List
>>> Subject: [CRYPTO]1.0.0 Release Plan
>>>
>>> Hello,
>>>
>>> Apache Commons CRYPTO was established at May 9, 2016[1], There are presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also fixed the legal issue[3].
>>>
>>> With the first release, we can begin to promote CRYPTO to other Apache components, like Apache Hadoop, Apache Spark, so that they can benefit the higher performance improvement from Apache Commons Crypto.
>>>
>>> We plan the following three opening features to next release(I think it should be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark tool[6]. Please let me know if there is anything need to be done before the release.
>>>
>>>
>>> Regards
>>> Dapeng
>>>
>>>
>>> [1]
>>> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CC
>>> AB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com
>>> %3E [2]
>>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&p
>>> id=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
>>> [3]
>>> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CC
>>> ACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.c
>>> om%3E [4] https://github.com/apache/commons-crypto/pull/44
>>> [5] https://github.com/apache/commons-crypto/pull/47
>>> [6] https://github.com/apache/commons-crypto/pull/1
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
> ---------------------------------------------------------------------
> 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

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Sun, Dapeng" <da...@intel.com>.

Thank Sebb for your great work!

About the Properties instance, I have some personal opinions.

I think properties provide a flexible configuration mechanism. Config values could be added and read/written without too much limitation, we also provides default values for each properties, user don't need set value for every properties. They could also give null, if they want to use the default settings.

>> also the way that classes are instantiated is very awkward, as properties are not as easy to use as plain variables - String/boolean etc and properties don't offer any type validation.

Properties don't offer any type validation, but we can validate the type and value before we using them. For example, stream buffer size, when CryptoStream is creating, it will read the value and convert it to int.

>> Since properties are used in the constructors, it's not enough for 3rd parties to just implement the CryptoRandom interface - they also have to provide a constructor which takes a Properties instance.

For 3rd parties implementations, they may need to read some configuration when initializing, properties will provide this ability at this time. Otherwise, they need to handle the work such as reading config file, read config value ant etc. For the 3rd parties implementations which don't need the properties, they can leave it null or ignore.

If you have a better configuration mechanism, could you tell me more detail?

Regards
Dapeng

-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com] 
Sent: Sunday, June 26, 2016 7:53 AM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

On 24 June 2016 at 11:17, sebb <se...@gmail.com> wrote:
> On 24 June 2016 at 10:08, Sun, Dapeng <da...@intel.com> wrote:
>> Hi all,
>>
>> Thank all for helping review CRYPTO from different angles.
>>
>> According the number of jira remaining issues, I prefer to start the thread for rolling a RC at June 29th(Next Wednesday). Please feel free to let me know if you have any concern about it.
>
> Yes, I do have some concerns.
>
> I think the public API needs to be better documented.
> There are still a lot of public classes that AFAICT don't really 
> belong in the API.
> For example
> JceCipher
> OpensslCipher
> JavaCryptoRandom
> OpensslCryptoRandom
> OsCryptoRandom
> These need to be made private/package protected or moved into an 
> internal package, or at the very least clearly documented as internal.

I have made them package private.

> Also the way that classes are instantiated is very awkward, as 
> properties are not as easy to use as plain variables - String/boolean 
> etc - and properties don't offer any type validation.
> Since properties are used in the constructors, it's not enough for 3rd 
> parties to just implement the CryptoRandom interface - they also have 
> to provide a constructor which takes a Properties instance.

This is still an issue.

> Indeed I wonder why there is a CryptoRandom interface - would it not 
> be better for JavaCryptoRandom to extend java.util.Random? The other 
> implementations of CryptoRandom do.
> Or maybe none of them should extend j.u.Random?

Likewise, this ought to be resolved.

>> Regards
>> Dapeng
>>
>> -----Original Message-----
>> From: Sun, Dapeng [mailto:dapeng.sun@intel.com]
>> Sent: Monday, June 06, 2016 5:14 PM
>> To: Commons Developers List
>> Subject: [CRYPTO]1.0.0 Release Plan
>>
>> Hello,
>>
>> Apache Commons CRYPTO was established at May 9, 2016[1], There are presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also fixed the legal issue[3].
>>
>> With the first release, we can begin to promote CRYPTO to other Apache components, like Apache Hadoop, Apache Spark, so that they can benefit the higher performance improvement from Apache Commons Crypto.
>>
>> We plan the following three opening features to next release(I think it should be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark tool[6]. Please let me know if there is anything need to be done before the release.
>>
>>
>> Regards
>> Dapeng
>>
>>
>> [1] 
>> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CC
>> AB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com
>> %3E [2] 
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&p
>> id=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
>> [3] 
>> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CC
>> ACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.c
>> om%3E [4] https://github.com/apache/commons-crypto/pull/44
>> [5] https://github.com/apache/commons-crypto/pull/47
>> [6] https://github.com/apache/commons-crypto/pull/1
>>
>>
>> ---------------------------------------------------------------------
>> 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


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

Re: [CRYPTO]1.0.0 Release Plan

Posted by sebb <se...@gmail.com>.

On 24 June 2016 at 11:17, sebb <se...@gmail.com> wrote:
> On 24 June 2016 at 10:08, Sun, Dapeng <da...@intel.com> wrote:
>> Hi all,
>>
>> Thank all for helping review CRYPTO from different angles.
>>
>> According the number of jira remaining issues, I prefer to start the thread for rolling a RC at June 29th(Next Wednesday). Please feel free to let me know if you have any concern about it.
>
> Yes, I do have some concerns.
>
> I think the public API needs to be better documented.
> There are still a lot of public classes that AFAICT don't really
> belong in the API.
> For example
> JceCipher
> OpensslCipher
> JavaCryptoRandom
> OpensslCryptoRandom
> OsCryptoRandom
> These need to be made private/package protected or moved into an
> internal package, or at the very least clearly documented as internal.

I have made them package private.

> Also the way that classes are instantiated is very awkward, as
> properties are not as easy to use as plain variables - String/boolean
> etc - and properties don't offer any type validation.
> Since properties are used in the constructors, it's not enough for 3rd
> parties to just implement the CryptoRandom interface - they also have
> to provide a constructor which takes a Properties instance.

This is still an issue.

> Indeed I wonder why there is a CryptoRandom interface - would it not
> be better for JavaCryptoRandom to extend java.util.Random? The other
> implementations of CryptoRandom do.
> Or maybe none of them should extend j.u.Random?

Likewise, this ought to be resolved.

>> Regards
>> Dapeng
>>
>> -----Original Message-----
>> From: Sun, Dapeng [mailto:dapeng.sun@intel.com]
>> Sent: Monday, June 06, 2016 5:14 PM
>> To: Commons Developers List
>> Subject: [CRYPTO]1.0.0 Release Plan
>>
>> Hello,
>>
>> Apache Commons CRYPTO was established at May 9, 2016[1], There are presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also fixed the legal issue[3].
>>
>> With the first release, we can begin to promote CRYPTO to other Apache components, like Apache Hadoop, Apache Spark, so that they can benefit the higher performance improvement from Apache Commons Crypto.
>>
>> We plan the following three opening features to next release(I think it should be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark tool[6]. Please let me know if there is anything need to be done before the release.
>>
>>
>> Regards
>> Dapeng
>>
>>
>> [1] http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E
>> [2] http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
>> [3] http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com%3E
>> [4] https://github.com/apache/commons-crypto/pull/44
>> [5] https://github.com/apache/commons-crypto/pull/47
>> [6] https://github.com/apache/commons-crypto/pull/1
>>
>>
>> ---------------------------------------------------------------------
>> 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

Re: [CRYPTO]1.0.0 Release Plan

Posted by sebb <se...@gmail.com>.

On 24 June 2016 at 10:08, Sun, Dapeng <da...@intel.com> wrote:
> Hi all,
>
> Thank all for helping review CRYPTO from different angles.
>
> According the number of jira remaining issues, I prefer to start the thread for rolling a RC at June 29th(Next Wednesday). Please feel free to let me know if you have any concern about it.

Yes, I do have some concerns.

I think the public API needs to be better documented.
There are still a lot of public classes that AFAICT don't really
belong in the API.
For example
JceCipher
OpensslCipher
JavaCryptoRandom
OpensslCryptoRandom
OsCryptoRandom
These need to be made private/package protected or moved into an
internal package, or at the very least clearly documented as internal.

Also the way that classes are instantiated is very awkward, as
properties are not as easy to use as plain variables - String/boolean
etc - and properties don't offer any type validation.
Since properties are used in the constructors, it's not enough for 3rd
parties to just implement the CryptoRandom interface - they also have
to provide a constructor which takes a Properties instance.

Indeed I wonder why there is a CryptoRandom interface - would it not
be better for JavaCryptoRandom to extend java.util.Random? The other
implementations of CryptoRandom do.
Or maybe none of them should extend j.u.Random?

> Regards
> Dapeng
>
> -----Original Message-----
> From: Sun, Dapeng [mailto:dapeng.sun@intel.com]
> Sent: Monday, June 06, 2016 5:14 PM
> To: Commons Developers List
> Subject: [CRYPTO]1.0.0 Release Plan
>
> Hello,
>
> Apache Commons CRYPTO was established at May 9, 2016[1], There are presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also fixed the legal issue[3].
>
> With the first release, we can begin to promote CRYPTO to other Apache components, like Apache Hadoop, Apache Spark, so that they can benefit the higher performance improvement from Apache Commons Crypto.
>
> We plan the following three opening features to next release(I think it should be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark tool[6]. Please let me know if there is anything need to be done before the release.
>
>
> Regards
> Dapeng
>
>
> [1] http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E
> [2] http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
> [3] http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com%3E
> [4] https://github.com/apache/commons-crypto/pull/44
> [5] https://github.com/apache/commons-crypto/pull/47
> [6] https://github.com/apache/commons-crypto/pull/1
>
>
> ---------------------------------------------------------------------
> 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

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Sun, Dapeng" <da...@intel.com>.

Hi all,

Thank all for helping review CRYPTO from different angles.

According the number of jira remaining issues, I prefer to start the thread for rolling a RC at June 29th(Next Wednesday). Please feel free to let me know if you have any concern about it.

Regards
Dapeng

-----Original Message-----
From: Sun, Dapeng [mailto:dapeng.sun@intel.com] 
Sent: Monday, June 06, 2016 5:14 PM
To: Commons Developers List
Subject: [CRYPTO]1.0.0 Release Plan

Hello,

Apache Commons CRYPTO was established at May 9, 2016[1], There are presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also fixed the legal issue[3].

With the first release, we can begin to promote CRYPTO to other Apache components, like Apache Hadoop, Apache Spark, so that they can benefit the higher performance improvement from Apache Commons Crypto.

We plan the following three opening features to next release(I think it should be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark tool[6]. Please let me know if there is anything need to be done before the release.


Regards
Dapeng


[1] http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E
[2] http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
[3] http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com%3E
[4] https://github.com/apache/commons-crypto/pull/44
[5] https://github.com/apache/commons-crypto/pull/47
[6] https://github.com/apache/commons-crypto/pull/1


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

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Sun, Dapeng" <da...@intel.com>.

> So we can assume the current master (commit
> a289ecd26257ac4ffaf1bbb686cf06b3a9ececdc) is buildable, right?

Yes, a289ecd26257ac4ffaf1bbb686cf06b3a9ececdc is buildable.

> https://github.com/apache/commons-crypto/blob/master/BUILDING.txt
> describes build requirements - in particular you need to have openssl library headers.

Good suggestion, I will add the requirements to BUILDING.txt

Regards
Dapeng

-----Original Message-----
From: Stian Soiland-Reyes [mailto:stain@apache.org] 
Sent: Monday, June 06, 2016 11:53 PM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

Makes sense for the first release.. like a pre-release candidate candidate, tested from git.

So we can assume the current master (commit
a289ecd26257ac4ffaf1bbb686cf06b3a9ececdc) is buildable, right?

https://github.com/apache/commons-crypto/blob/master/BUILDING.txt

describes build requirements - in particular you need to have openssl library headers.

On 6 June 2016 at 15:53, Gary Gregory <ga...@gmail.com> wrote:
> Why don't you give us a couple of days before rolling an RC, I for 
> one, would like to review the project a little more carefully. This 
> would avoid wasting time on failed RCs and give an opportunity for 
> others committers and PMC members to make any changes they think 
> should be be done. Could be things like reviewing PMD, CPD, and 
> Checkstyle reports, and so on. Mayve announce something like, "I plan 
> on rolling an RC and Friday" or something like that.
>
> Gary
> On Jun 6, 2016 2:49 AM, "Benedikt Ritter" <br...@apache.org> wrote:
>
>> Hello Dapeng
>>
>> Sun, Dapeng <da...@intel.com> schrieb am Mo., 6. Juni 2016 um
>> 11:13 Uhr:
>>
>> > Hello,
>> >
>> > Apache Commons CRYPTO was established at May 9, 2016[1], There are 
>> > presently numbers of resolved issues fix in CRYPTO[2]. Recently, we 
>> > also fixed the legal issue[3].
>> >
>> > With the first release, we can begin to promote CRYPTO to other 
>> > Apache components, like Apache Hadoop, Apache Spark, so that they 
>> > can benefit
>> the
>> > higher performance improvement from Apache Commons Crypto.
>> >
>> > We plan the following three opening features to next release(I 
>> > think it should be 1.1.0): GCM support[4], JNACipher 
>> > implementation[5] and
>> benchmark
>> > tool[6]. Please let me know if there is anything need to be done 
>> > before
>> the
>> > release.
>> >
>> >
>> Sounds good to me. Let me know if you need help preparing the RC.
>>
>> Benedikt
>>
>>
>> >
>> > Regards
>> > Dapeng
>> >
>> >
>> > [1]
>> >
>> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CC
>> AB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com
>> %3E
>> > [2]
>> >
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&p
>> id=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
>> > [3]
>> >
>> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CC
>> ACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.c
>> om%3E
>> > [4] https://github.com/apache/commons-crypto/pull/44
>> > [5] https://github.com/apache/commons-crypto/pull/47
>> > [6] https://github.com/apache/commons-crypto/pull/1
>> >
>> >
>>



--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/0000-0001-9842-9718

---------------------------------------------------------------------
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

Re: [CRYPTO]1.0.0 Release Plan

Posted by Stian Soiland-Reyes <st...@apache.org>.

Makes sense for the first release.. like a pre-release candidate
candidate, tested from git.

So we can assume the current master (commit
a289ecd26257ac4ffaf1bbb686cf06b3a9ececdc) is buildable, right?

https://github.com/apache/commons-crypto/blob/master/BUILDING.txt

describes build requirements - in particular you need to have openssl
library headers.

On 6 June 2016 at 15:53, Gary Gregory <ga...@gmail.com> wrote:
> Why don't you give us a couple of days before rolling an RC, I for one,
> would like to review the project a little more carefully. This would avoid
> wasting time on failed RCs and give an opportunity for others committers
> and PMC members to make any changes they think should be be done. Could be
> things like reviewing PMD, CPD, and Checkstyle reports, and so on. Mayve
> announce something like, "I plan on rolling an RC and Friday" or something
> like that.
>
> Gary
> On Jun 6, 2016 2:49 AM, "Benedikt Ritter" <br...@apache.org> wrote:
>
>> Hello Dapeng
>>
>> Sun, Dapeng <da...@intel.com> schrieb am Mo., 6. Juni 2016 um
>> 11:13 Uhr:
>>
>> > Hello,
>> >
>> > Apache Commons CRYPTO was established at May 9, 2016[1], There are
>> > presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also
>> > fixed the legal issue[3].
>> >
>> > With the first release, we can begin to promote CRYPTO to other Apache
>> > components, like Apache Hadoop, Apache Spark, so that they can benefit
>> the
>> > higher performance improvement from Apache Commons Crypto.
>> >
>> > We plan the following three opening features to next release(I think it
>> > should be 1.1.0): GCM support[4], JNACipher implementation[5] and
>> benchmark
>> > tool[6]. Please let me know if there is anything need to be done before
>> the
>> > release.
>> >
>> >
>> Sounds good to me. Let me know if you need help preparing the RC.
>>
>> Benedikt
>>
>>
>> >
>> > Regards
>> > Dapeng
>> >
>> >
>> > [1]
>> >
>> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E
>> > [2]
>> >
>> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
>> > [3]
>> >
>> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com%3E
>> > [4] https://github.com/apache/commons-crypto/pull/44
>> > [5] https://github.com/apache/commons-crypto/pull/47
>> > [6] https://github.com/apache/commons-crypto/pull/1
>> >
>> >
>>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/0000-0001-9842-9718

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

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Sun, Dapeng" <da...@intel.com>.

Thank Gary for reviewing the project.

> Mayve announce something like, "I plan on rolling an RC and Friday" or something like that
It's a good suggestion. I think the date can be June 13th (the Next Monday). I will send another email with the date.

Regards
Dapeng

-----Original Message-----
From: Gary Gregory [mailto:garydgregory@gmail.com] 
Sent: Monday, June 06, 2016 10:53 PM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

Why don't you give us a couple of days before rolling an RC, I for one, would like to review the project a little more carefully. This would avoid wasting time on failed RCs and give an opportunity for others committers and PMC members to make any changes they think should be be done. Could be things like reviewing PMD, CPD, and Checkstyle reports, and so on. Mayve announce something like, "I plan on rolling an RC and Friday" or something like that.

Gary
On Jun 6, 2016 2:49 AM, "Benedikt Ritter" <br...@apache.org> wrote:

> Hello Dapeng
>
> Sun, Dapeng <da...@intel.com> schrieb am Mo., 6. Juni 2016 um
> 11:13 Uhr:
>
> > Hello,
> >
> > Apache Commons CRYPTO was established at May 9, 2016[1], There are 
> > presently numbers of resolved issues fix in CRYPTO[2]. Recently, we 
> > also fixed the legal issue[3].
> >
> > With the first release, we can begin to promote CRYPTO to other 
> > Apache components, like Apache Hadoop, Apache Spark, so that they 
> > can benefit
> the
> > higher performance improvement from Apache Commons Crypto.
> >
> > We plan the following three opening features to next release(I think 
> > it should be 1.1.0): GCM support[4], JNACipher implementation[5] and
> benchmark
> > tool[6]. Please let me know if there is anything need to be done 
> > before
> the
> > release.
> >
> >
> Sounds good to me. Let me know if you need help preparing the RC.
>
> Benedikt
>
>
> >
> > Regards
> > Dapeng
> >
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCA
> B917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3
> E
> > [2]
> >
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pi
> d=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
> > [3]
> >
> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCA
> CZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com
> %3E
> > [4] https://github.com/apache/commons-crypto/pull/44
> > [5] https://github.com/apache/commons-crypto/pull/47
> > [6] https://github.com/apache/commons-crypto/pull/1
> >
> >
>

Re: [CRYPTO]1.0.0 Release Plan

Posted by Gary Gregory <ga...@gmail.com>.

Why don't you give us a couple of days before rolling an RC, I for one,
would like to review the project a little more carefully. This would avoid
wasting time on failed RCs and give an opportunity for others committers
and PMC members to make any changes they think should be be done. Could be
things like reviewing PMD, CPD, and Checkstyle reports, and so on. Mayve
announce something like, "I plan on rolling an RC and Friday" or something
like that.

Gary
On Jun 6, 2016 2:49 AM, "Benedikt Ritter" <br...@apache.org> wrote:

> Hello Dapeng
>
> Sun, Dapeng <da...@intel.com> schrieb am Mo., 6. Juni 2016 um
> 11:13 Uhr:
>
> > Hello,
> >
> > Apache Commons CRYPTO was established at May 9, 2016[1], There are
> > presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also
> > fixed the legal issue[3].
> >
> > With the first release, we can begin to promote CRYPTO to other Apache
> > components, like Apache Hadoop, Apache Spark, so that they can benefit
> the
> > higher performance improvement from Apache Commons Crypto.
> >
> > We plan the following three opening features to next release(I think it
> > should be 1.1.0): GCM support[4], JNACipher implementation[5] and
> benchmark
> > tool[6]. Please let me know if there is anything need to be done before
> the
> > release.
> >
> >
> Sounds good to me. Let me know if you need help preparing the RC.
>
> Benedikt
>
>
> >
> > Regards
> > Dapeng
> >
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E
> > [2]
> >
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
> > [3]
> >
> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com%3E
> > [4] https://github.com/apache/commons-crypto/pull/44
> > [5] https://github.com/apache/commons-crypto/pull/47
> > [6] https://github.com/apache/commons-crypto/pull/1
> >
> >
>

RE: [CRYPTO]1.0.0 Release Plan

Posted by "Sun, Dapeng" <da...@intel.com>.

Thank Benedikt.

Regards
Dapeng

-----Original Message-----
From: Benedikt Ritter [mailto:britter@apache.org] 
Sent: Monday, June 06, 2016 5:50 PM
To: Commons Developers List
Subject: Re: [CRYPTO]1.0.0 Release Plan

Hello Dapeng

Sun, Dapeng <da...@intel.com> schrieb am Mo., 6. Juni 2016 um
11:13 Uhr:

> Hello,
>
> Apache Commons CRYPTO was established at May 9, 2016[1], There are 
> presently numbers of resolved issues fix in CRYPTO[2]. Recently, we 
> also fixed the legal issue[3].
>
> With the first release, we can begin to promote CRYPTO to other Apache 
> components, like Apache Hadoop, Apache Spark, so that they can benefit 
> the higher performance improvement from Apache Commons Crypto.
>
> We plan the following three opening features to next release(I think 
> it should be 1.1.0): GCM support[4], JNACipher implementation[5] and 
> benchmark tool[6]. Please let me know if there is anything need to be 
> done before the release.
>
>
Sounds good to me. Let me know if you need help preparing the RC.

Benedikt


>
> Regards
> Dapeng
>
>
> [1]
> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCA
> B917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3
> E
> [2]
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pi
> d=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
> [3]
> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCA
> CZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com
> %3E [4] https://github.com/apache/commons-crypto/pull/44
> [5] https://github.com/apache/commons-crypto/pull/47
> [6] https://github.com/apache/commons-crypto/pull/1
>
>

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

Re: [CRYPTO]1.0.0 Release Plan

Posted by Benedikt Ritter <br...@apache.org>.

Hello Dapeng

Sun, Dapeng <da...@intel.com> schrieb am Mo., 6. Juni 2016 um
11:13 Uhr:

> Hello,
>
> Apache Commons CRYPTO was established at May 9, 2016[1], There are
> presently numbers of resolved issues fix in CRYPTO[2]. Recently, we also
> fixed the legal issue[3].
>
> With the first release, we can begin to promote CRYPTO to other Apache
> components, like Apache Hadoop, Apache Spark, so that they can benefit the
> higher performance improvement from Apache Commons Crypto.
>
> We plan the following three opening features to next release(I think it
> should be 1.1.0): GCM support[4], JNACipher implementation[5] and benchmark
> tool[6]. Please let me know if there is anything need to be done before the
> release.
>
>
Sounds good to me. Let me know if you need help preparing the RC.

Benedikt


>
> Regards
> Dapeng
>
>
> [1]
> http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E
> [2]
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=12310464&sorter/field=issuekey&sorter/order=DESC&status=5&status=6
> [3]
> http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com%3E
> [4] https://github.com/apache/commons-crypto/pull/44
> [5] https://github.com/apache/commons-crypto/pull/47
> [6] https://github.com/apache/commons-crypto/pull/1
>
>