Re: [crypto] On Java 6, really?

[Gangumalla, Uma]

On 6/14/16, 1:23 AM, "Gary Gregory" <garydgreg...@gmail.com> wrote:

>On Tue, Jun 14, 2016 at 1:21 AM, Gangumalla, Uma
><uma.ganguma...@intel.com>
>wrote:
>
>> Then next release(after 1.0.0) must be a major release you mean?
>> If there are no potential users looking for JDK 1.6, dropping now should
>> be good idea IMO.
>>
>> I also remembered that we wanted to mark 1.0.0 release as Alpha right?
>> (just a question)
>>
>
>1.0 is 1.0. If we want an alpha, we must label is as such, for example
>1.0-alpha1, 1.0-beta1. There is no 1.0 is an alpha and 1.1 is a "real"
>release.

Yeah, right on naming.
What others think on that?
>
>Gary
>
>>
>> Regards,
>> Uma
>>
>> On 6/14/16, 12:27 AM, "Sun, Dapeng" <dapeng@intel.com> wrote:
>>
>> >Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and
>>Matt
>> >for all your input.
>> >
>> >How about make a conservative decision: regarding the first
>> >release(1.0.0), we keep the JDK version as 1.6, and we wouldn't support
>> >JDK 1.6 for the releases after 1.0.0.
>> >
>> >Regards
>> >Dapeng
>> >
>> >-Original Message-
>> >From: Matt Sicker [mailto:boa...@gmail.com]
>> >Sent: Wednesday, June 08, 2016 6:18 AM
>> >To: Commons Developers List
>> >Subject: Re: [crypto] On Java 6, really?
>> >
>> >I'd imagine that close to 100% of users who are on Java 6 are not
>> >upgrading anything else, either, nor would they be adding in new
>> >dependencies. Every Java 6 project I've come across lately has been in
>> >legacy maintenance mode (just like Java 6 itself).
>> >
>> >On 7 June 2016 at 16:47, Gary Gregory <garydgreg...@gmail.com> wrote:
>> >
>> >> Let's not forget that customers are paying Oracle to get Java 6
>>updates.
>> >>
>> >> Gary
>> >> On Jun 7, 2016 1:24 PM, "Ralph Goers" <ralph.go...@dslextreme.com>
>> >>wrote:
>> >>
>> >> > I really don¹t think the premier & extended support dates should
>> >> > really mean much, except as an indicator of how many users of that
>> >> > version might still exist.  Basically, no new features are going to
>> >> > be added to Java
>> >> so I
>> >> > don¹t think we should be targeting new features there either. If
>> >> > there
>> >> is a
>> >> > bug that needs to be fixed it should be possible to do it on a
>> >> > branch of the the release for that version of Java.  The web site
>> >> > should clearly indicate which versions of the component support the
>> >> > appropriate Java versions.
>> >> >
>> >> > Ralph
>> >> >
>> >> > > On Jun 7, 2016, at 12:26 PM, sebb <seb...@gmail.com> wrote:
>> >> > >
>> >> > > I have just checked Oracle support for Java 6.
>> >> > >
>> >> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I
>> >> > > think this means that there are critical systems that cannot yet
>> >> > > be updated to Java 7+.
>> >> > >
>> >> > > This does not mean that we should ensure that all Commons code
>> >> > > still works on Java 6.
>> >> > > But it should be taken into account when evaluating the pros and
>> >> > > cons of requiring a later version.
>> >> > >
>> >> > > [1]
>> >> > > http://www.oracle.com/technetwork/java/eol-135779.html#extended6
>> >> > >
>> >> > > On 7 June 2016 at 20:02, Jochen Wiedmann
>> >> > > <jochen.wiedm...@gmail.com>
>> >> > wrote:
>> >> > >>> Gary Gregory <garydgreg...@gmail.com> wrote on Tue., 7. Juni
>> >> > >>> 2016
>> >> > >>>
>> >> > >>>> Are we really starting a new component on a dead platform like
>> >> > >>>> Java
>> >> 6?
>> >> > >>
>> >> > >>
>> >> > >> You are, of course, right, that the component is more than
>> >> > >> welcome to use another version. OTOH, given our latest
>> >> > >> experiences: Is this really someting, that we should care for?
>> >> > >>

Re: [crypto] On Java 6, really?

[Gangumalla, Uma]

Then next release(after 1.0.0) must be a major release you mean?
If there are no potential users looking for JDK 1.6, dropping now should
be good idea IMO.

I also remembered that we wanted to mark 1.0.0 release as Alpha right?
(just a question)

Regards,
Uma

On 6/14/16, 12:27 AM, "Sun, Dapeng"  wrote:

>Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and Matt
>for all your input.
>
>How about make a conservative decision: regarding the first
>release(1.0.0), we keep the JDK version as 1.6, and we wouldn't support
>JDK 1.6 for the releases after 1.0.0.
>
>Regards
>Dapeng
>
>-Original Message-
>From: Matt Sicker [mailto:boa...@gmail.com]
>Sent: Wednesday, June 08, 2016 6:18 AM
>To: Commons Developers List
>Subject: Re: [crypto] On Java 6, really?
>
>I'd imagine that close to 100% of users who are on Java 6 are not
>upgrading anything else, either, nor would they be adding in new
>dependencies. Every Java 6 project I've come across lately has been in
>legacy maintenance mode (just like Java 6 itself).
>
>On 7 June 2016 at 16:47, Gary Gregory  wrote:
>
>> Let's not forget that customers are paying Oracle to get Java 6 updates.
>>
>> Gary
>> On Jun 7, 2016 1:24 PM, "Ralph Goers" 
>>wrote:
>>
>> > I really don¹t think the premier & extended support dates should
>> > really mean much, except as an indicator of how many users of that
>> > version might still exist.  Basically, no new features are going to
>> > be added to Java
>> so I
>> > don¹t think we should be targeting new features there either. If
>> > there
>> is a
>> > bug that needs to be fixed it should be possible to do it on a
>> > branch of the the release for that version of Java.  The web site
>> > should clearly indicate which versions of the component support the
>> > appropriate Java versions.
>> >
>> > Ralph
>> >
>> > > On Jun 7, 2016, at 12:26 PM, sebb  wrote:
>> > >
>> > > I have just checked Oracle support for Java 6.
>> > >
>> > > The Support Life for Java 6 has been extended to Dec 2018 [1] I
>> > > think this means that there are critical systems that cannot yet
>> > > be updated to Java 7+.
>> > >
>> > > This does not mean that we should ensure that all Commons code
>> > > still works on Java 6.
>> > > But it should be taken into account when evaluating the pros and
>> > > cons of requiring a later version.
>> > >
>> > > [1] 
>> > > http://www.oracle.com/technetwork/java/eol-135779.html#extended6
>> > >
>> > > On 7 June 2016 at 20:02, Jochen Wiedmann
>> > > 
>> > wrote:
>> > >>> Gary Gregory  wrote on Tue., 7. Juni
>> > >>> 2016
>> > >>>
>> >  Are we really starting a new component on a dead platform like
>> >  Java
>> 6?
>> > >>
>> > >>
>> > >> You are, of course, right, that the component is more than
>> > >> welcome to use another version. OTOH, given our latest
>> > >> experiences: Is this really someting, that we should care for?
>> > >> IMO, let the component have, whatever they want.
>> > >>
>> > >> Jochen
>> > >>
>> > >> -
>> > >>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > >> For additional commands, e-mail: dev-h...@commons.apache.org
>> > >>
>> > >
>> > > --
>> > > --- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > > For additional commands, e-mail: dev-h...@commons.apache.org
>> > >
>> > >
>> >
>> >
>> >
>> > 
>> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>>
>
>
>
>--
>Matt Sicker 


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

Re: [crypto] The standard indentation is 4 spaces per indent

[Gangumalla, Uma]

>This is Commons, AND this is brand new code, so in my mind there is no
"original" formatting style to respect. 4 spaces per indent like the rest
of the project please. Remember that Commons is a SINGLE project. Hopefully
we won't have to argue about too much about this...
[Uma] Thanks Gary for your opinion on this. I think I confused on the part
respect "original code". Since we got original code from Hadoop (Chimera
pulled the code from Hadoop), I brought this point. My proposal also says
that, original source of code is from Hadoop. I realized that, point says
about the component coding style for new contributions. BTW, Yes, its not
worth discussing too much on this point :-). I am ok either way.

Regards,
Uma

On 4/28/16, 10:17 PM, "Gary Gregory"  wrote:

>This is Commons, AND this is brand new code, so in my mind there is no
>"original" formatting style to respect. 4 spaces per indent like the rest
>of the project please. Remember that Commons is a SINGLE project.
>Hopefully
>we won't have to argue about too much about this...


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

Re: [CRYPTO] Switch from JNI to JNA

[Gangumalla, Uma]

This is awesome. Thanks Haifeng for driving towards 1st release.

Regards,
Uma

On 4/26/16, 6:27 PM, "Chen, Haifeng"  wrote:

>Thanks folks.
>An alpha release is a good suggestion! I am checking with the Spark guys
>as to the Spark 2.0 code freeze timeline and check whether we can meet it
>with an alpha release
>While at Commons, we try move fast to make everything clean. Try best
>stabilize the API.
>
>If folks in community has different ideas, please free feel to raise up.
>
>Regards,
>Haifeng
>
>-Original Message-
>From: Gary Gregory [mailto:garydgreg...@gmail.com]
>Sent: Tuesday, April 26, 2016 10:50 AM
>To: Commons Developers List 
>Subject: Re: [CRYPTO] Switch from JNI to JNA
>
>I like it. RERO!
>As we plan to have release sooner, marking release ALPHA tagged make
>sense IMO.
>
>Regards,
>Uma
>On 4/25/16, 7:02 PM, "sebb"  wrote:
>
>>On 26 April 2016 at 02:56, Chen, Haifeng  wrote:
> Sounds like a tough time schedule. It's only one week until May.
>>> Yeah, it's a tough time schedule. We will just try moving fast and
>>>see what we can reach at that time. Maybe it's not realistic in one
>>>week.
>>
>>It's expensive to change the public API once released.
>>
>>Given the timescale, maybe it would work to release an ALPHA version on
>>the understanding that the API may change incompatibly.
>>
>>> -Original Message-
>>> From: Benedikt Ritter [mailto:brit...@apache.org]
>>> Sent: Tuesday, April 26, 2016 12:03 AM
>>> To: Commons Developers List 
>>> Subject: Re: [CRYPTO] Switch from JNI to JNA
>>>
>>> Chen, Haifeng  schrieb am Mo., 25. Apr. 2016
>>> um
>>> 08:38 Uhr:
>>>
 >> Maybe its an option to replace JNI by JNA [1]. This would have
 >> IHMO
 several advantages like
 >> * No C code needs to be written, compiled, tested and maintained
 >> * Its easier compared to JNI (this could help attracting more
 >> people to
 contribute)
 >> * Many supported platforms [2], precompiled native binaries
 >> available
 Agree on these advantages.

 >> Disadvantages:
 >> * Introduce a dependency to JNA
 >> * Performance decrease compared to JNI (direct buffers and direct
 mapping helps minimizing this) [3]
 The major concern will be on the performance. Because the major
 value for Crypto is to utilize the performance optimization OpenSSL
provided.
 Need to have an evaluation on how much performance penalty will
 occur when using JNA comparing JNI.

 The Spark community are eager to utilize this library. If we can
have  the first release before May, there is a possibility to include
it in Spark 2.0.

>>>
>>> Sounds like a tough time schedule. It's only one week until May.
>>>
>>>
 Any idea to put JNA evaluation in the second release?
>>>
>>>
>>> Yes, why not.
>>>
>>>

 Thanks,
 Haifeng

 -Original Message-
 From: Hendrik Dev [mailto:hendrikde...@gmail.com]
 Sent: Saturday, April 23, 2016 6:43 PM
 To: Commons Developers List 
 Subject: [CRYPTO] Switch from JNI to JNA

 Hi,

 i just had a brief look into commons crypto today.
 Maybe its an option to replace JNI by JNA [1]. This would have IHMO
 several advantages like

 * No C code needs to be written, compiled, tested and maintained
 * Its easier compared to JNI (this could help attracting more people
 to
 contribute)
 * Many supported platforms [2], precompiled native binaries
 available

 Disadvantages:

 * Introduce a dependency to JNA
 * Performance decrease compared to JNI (direct buffers and direct
 mapping helps minimizing this) [3]

 I prepared a demo [4] to show thats its generally working and how a
 implementation could like (although tests are not working and error
 handling is missing).

 [1] https://github.com/java-native-access/jna
 [2] https://github.com/java-native-access/jna/tree/master/lib/native
 [3] https://s.apache.org/q5Tl
 [4] https://s.apache.org/DQeD

 Wdyt?

 Thanks
 Hendrik

 --
 Hendrik Saly (salyh, hendrikdev22)
 @hendrikdev22
 PGP: 0x22D7F6EC

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


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

Re: [crypto] The standard indentation is 4 spaces per indent

[Gangumalla, Uma]

I am ok with a JIRA and type could be task for the reasons Sebb mentioned
below.

But I prefer to keep 2 spaces if others also ok who is going to involve in
development. I assume most of Hadoop devs would have set their indentation
2 already in their IDEs. So, here also most of them would involve with
indentation space 2 in their IDEs. If that does not hurt other, how about
keeping 2?

It will make easy to identify the default tabs(tab with 4char space) from
IDEs like eclipse if code format settings are with 2 spaces. Ex: When some
new contributor forgot to modify their IDE setting with spaces, then code
will be easily identifiable if that has default setting with tabs. But
with 4 spaces, it will look same.

I just read it from Commons site: (Copied from site
https://commons.apache.org/patches.html)
Respect The Original Style
Please respect the style of the orginal file. Make sure that your
additions fit in with that style.
Every component has coding conventions and every contribution is supposed
to adhere to them. You might find it a little difficult to discover the
conventions used by a particular component but if you stick to the style
of the original then that'll be fine.
If a patch is submitted which doesn't satisfy the component's coding
conventions, then either a committer will need to rewrite the submission
or it will be rejected. Getting it right in this first place will save you
having to rewrite it.

It says that we can continue with original coding format if we want. But
anyway we can decide now.



Regards,
Uma

On 4/26/16, 3:06 AM, "sebb"  wrote:

>On 26 April 2016 at 03:07, Chen, Haifeng  wrote:
>> Hi Gary,
>>
 Do you really want this level of Jira tracking? It seems over the top
to me. Is this process style for this component? In this case I would
just do it and not Jira it. Then for detailed history, you just look
at the commit history. Or are you just using Jira as a to-do list in
the early days of this component in its new home in Apache Commons?
>> As when we are working in Hadoop projects, we need a JIRA to start a
>>work and communicate with the community. I am not sure whether Apache
>>Commons allows commit of code without JIRA at this project stage. So I
>>just try to do it in a safe way in a new family:)
>> If Apache Commons folks thinks it's OK to do it without JIRA, I am OK
>>with it.
>
>If a developer spots a typo or missing/unclear Javadoc, I would say
>just fix it rather than raising a JIRA.
>
>This case is borderline to me since it affects the whole codebase.
>And the change impacts on how easy it is to see where/when changes were
>made.
>(This is more intrusive than a package name change at least as far as
>history is concerned since every line may be changed)
>Also it ideally needs to be co-ordinated with other changes.
>
>So I think it would be wrong to commit the change without some prior
>notification.
>This can either be a JIRA or agreement on the dev list.
>
>> Regards,
>> Haifeng
>>
>> -Original Message-
>> From: Gary Gregory [mailto:garydgreg...@gmail.com]
>> Sent: Tuesday, April 26, 2016 9:53 AM
>> To: Commons Developers List 
>> Subject: RE: [crypto] The standard indentation is 4 spaces per indent
>>
>> Hi,
>>
>> Do you really want this level of Jira tracking? It seems over the top
>>to me. Is this process style for this component? In this case I would
>>just do it and not Jira it. Then for detailed history, you just look at
>>the commit history. Or are you just using Jira as a to-do list in the
>>early days of this component in its new home in Apache Commons?
>>
>> Gary
>> On Apr 25, 2016 6:47 PM, "Chen, Haifeng"  wrote:
>>
In our coding guidelines [1] we say that "The standard indentation is
4
>> spaces per indent - but respect the number of spaces used by the
>>original."
The [crypto] Java code I've seen to far is all 2 spaces per indent.
I think now is the time to do this, most IDEs can do a one-shot format
of
>> a whole source tree.
>> Good catch, Gary. The original code was based on Hadoop format style
>>which is 2 spaces indent. I will fire a JIRA to format that.
>>
>> Thanks,
>> Haifeng
>>
>> -Original Message-
>> From: Gary Gregory [mailto:garydgreg...@gmail.com]
>> Sent: Tuesday, April 26, 2016 6:25 AM
>> To: Commons Developers List 
>> Subject: [crypto] The standard indentation is 4 spaces per indent
>>
>> Hi all,
>>
>> In our coding guidelines [1] we say that "The standard indentation is 4
>>spaces per indent - but respect the number of spaces used by the
>>original."
>>
>> The [crypto] Java code I've seen to far is all 2 spaces per indent.
>>
>> I think now is the time to do this, most IDEs can do a one-shot format
>>of a whole source tree.
>>
>> Gary
>>
>> [1] https://commons.apache.org/patches.html
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence

Re: [CRYPTO] Switch from JNI to JNA

[Gangumalla, Uma]

As we plan to have release sooner, marking release ALPHA tagged make sense
IMO. 

Regards,
Uma
On 4/25/16, 7:02 PM, "sebb"  wrote:

>On 26 April 2016 at 02:56, Chen, Haifeng  wrote:
 Sounds like a tough time schedule. It's only one week until May.
>> Yeah, it's a tough time schedule. We will just try moving fast and see
>>what we can reach at that time. Maybe it's not realistic in one week.
>
>It's expensive to change the public API once released.
>
>Given the timescale, maybe it would work to release an ALPHA version
>on the understanding that the API may change incompatibly.
>
>> -Original Message-
>> From: Benedikt Ritter [mailto:brit...@apache.org]
>> Sent: Tuesday, April 26, 2016 12:03 AM
>> To: Commons Developers List 
>> Subject: Re: [CRYPTO] Switch from JNI to JNA
>>
>> Chen, Haifeng  schrieb am Mo., 25. Apr. 2016 um
>> 08:38 Uhr:
>>
>>> >> Maybe its an option to replace JNI by JNA [1]. This would have IHMO
>>> several advantages like
>>> >> * No C code needs to be written, compiled, tested and maintained
>>> >> * Its easier compared to JNI (this could help attracting more
>>> >> people to
>>> contribute)
>>> >> * Many supported platforms [2], precompiled native binaries
>>> >> available
>>> Agree on these advantages.
>>>
>>> >> Disadvantages:
>>> >> * Introduce a dependency to JNA
>>> >> * Performance decrease compared to JNI (direct buffers and direct
>>> mapping helps minimizing this) [3]
>>> The major concern will be on the performance. Because the major value
>>> for Crypto is to utilize the performance optimization OpenSSL provided.
>>> Need to have an evaluation on how much performance penalty will occur
>>> when using JNA comparing JNI.
>>>
>>> The Spark community are eager to utilize this library. If we can have
>>> the first release before May, there is a possibility to include it in
>>>Spark 2.0.
>>>
>>
>> Sounds like a tough time schedule. It's only one week until May.
>>
>>
>>> Any idea to put JNA evaluation in the second release?
>>
>>
>> Yes, why not.
>>
>>
>>>
>>> Thanks,
>>> Haifeng
>>>
>>> -Original Message-
>>> From: Hendrik Dev [mailto:hendrikde...@gmail.com]
>>> Sent: Saturday, April 23, 2016 6:43 PM
>>> To: Commons Developers List 
>>> Subject: [CRYPTO] Switch from JNI to JNA
>>>
>>> Hi,
>>>
>>> i just had a brief look into commons crypto today.
>>> Maybe its an option to replace JNI by JNA [1]. This would have IHMO
>>> several advantages like
>>>
>>> * No C code needs to be written, compiled, tested and maintained
>>> * Its easier compared to JNI (this could help attracting more people
>>> to
>>> contribute)
>>> * Many supported platforms [2], precompiled native binaries available
>>>
>>> Disadvantages:
>>>
>>> * Introduce a dependency to JNA
>>> * Performance decrease compared to JNI (direct buffers and direct
>>> mapping helps minimizing this) [3]
>>>
>>> I prepared a demo [4] to show thats its generally working and how a
>>> implementation could like (although tests are not working and error
>>> handling is missing).
>>>
>>> [1] https://github.com/java-native-access/jna
>>> [2] https://github.com/java-native-access/jna/tree/master/lib/native
>>> [3] https://s.apache.org/q5Tl
>>> [4] https://s.apache.org/DQeD
>>>
>>> Wdyt?
>>>
>>> Thanks
>>> Hendrik
>>>
>>> --
>>> Hendrik Saly (salyh, hendrikdev22)
>>> @hendrikdev22
>>> PGP: 0x22D7F6EC
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org
>


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

Re: [CRYPTO] Git repository requested

[Gangumalla, Uma]

Looks like access already has been granted. Please looks here if any one
missing. http://home.apache.org/phonebook.html?unix=commons

Regards,
Uma

On 4/19/16, 7:40 PM, "Chen, Haifeng" <haifeng.c...@intel.com> wrote:

>Thanks for the reminding. Confirmed that the code imported correctly. Has
>commented there and wait for the lock to be lifted.
>The building, renaming and doc tasks are in working and the tracking
>JIRAs have been created.
>
>Benedikt, one thing to check, does the initial committers already gain
>write access to Crypto repository or we need additional step to setup?
>
>Regards,
>Haifeng
>
>-Original Message-
>From: Benedikt Ritter [mailto:brit...@apache.org]
>Sent: Tuesday, April 19, 2016 5:23 AM
>To: Commons Developers List <dev@commons.apache.org>
>Subject: Re: [CRYPTO] Git repository requested
>
>Hi,
>
>Chen, Haifeng <haifeng.c...@intel.com> schrieb am Mo., 18. Apr. 2016 um
>08:38 Uhr:
>
>> Hi folks,
>> I have configured the versions and components for the JIRA project for
>> Apache Commons Crypto.
>>
>> And I also commented in
>> https://issues.apache.org/jira/browse/INFRA-11627
>> to ask Daniel to lift the lock on the git repository.
>> Benedikt, I don't have to permission to change INFRA-11627 to the
>> status "Waiting for Infra", If you think it is necessary, please help
>>to change.
>>
>
>Gavin has already commented. He needs your confirmation that everything
>is as expected.
>
>Regards,
>Benedikt
>
>
>>
>> Regards,
>> Haifeng
>>
>> -Original Message-
>> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
>> Sent: Monday, April 18, 2016 9:44 AM
>> To: Commons Developers List <dev@commons.apache.org>
>> Subject: RE: [CRYPTO] Git repository requested
>>
>> Thank you, Benedikt.
>> Will start to do that.
>>
>>
>> -Original Message-
>> From: Benedikt Ritter [mailto:brit...@apache.org]
>> Sent: Friday, April 15, 2016 3:48 PM
>> To: Commons Developers List <dev@commons.apache.org>
>> Subject: Re: [CRYPTO] Git repository requested
>>
>> I have added both of you to the commons-developers list. You should be
>> able to configure the project as you see fit.
>>
>> Benedikt
>>
>> Chen, Haifeng <haifeng.c...@intel.com> schrieb am Fr., 15. Apr. 2016
>> um
>> 03:32 Uhr:
>>
>> > Thanks Benedikt!
>> > My JIRA username is: jerrychenhf
>> >
>> > Regards,
>> > Haifeng
>> >
>> > -Original Message-
>> > From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
>> > Sent: Friday, April 15, 2016 3:40 AM
>> > To: Commons Developers List <dev@commons.apache.org>
>> > Subject: Re: [CRYPTO] Git repository requested
>> >
>> >
>> > Hi Benedikt,
>> >
>> >  Here is my username: umamaheswararao
>> >
>> > Regards,
>> > Uma
>> >
>> > On 4/14/16, 5:55 AM, "Benedikt Ritter" <brit...@apache.org> wrote:
>> >
>> > >Benedikt Ritter <brit...@apache.org> schrieb am Mi., 13. Apr. 2016
>> > >um
>> > >11:09 Uhr:
>> > >
>> > >> Chen, Haifeng <haifeng.c...@intel.com> schrieb am Mi., 13. Apr.
>> > >> 2016 um
>> > >> 05:18 Uhr:
>> > >>
>> > >>> The git repository for Apache Commons Crypto has been created.
>> > >>> It is locked so commits won't be accepted for now, will inform
>> > >>> Daniel when we want the lock lifted.
>> > >>> https://git-wip-us.apache.org/repos/asf?p=commons-crypto.git
>> > >>>
>> > >>> Next we may need to setup a JIRA project and the initial
>>committers.
>> > >>> Thanks to Dianel, Benedikt, and Uma.
>> > >>>
>> > >>> - [DONE]vote for Chimera to join Apache Commons
>> > >>> - [DONE]decide on a name for the new component (Apache Commons
>> > >>> Crypto)
>> > >>> - [DONE]move code to an Apache repo (probably git)
>> > >>> - request a Jira project
>> > >>>
>> > >>
>> > >> Request created:
>> > >> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFR
>> > >> A-
>> > >> 11
>> > >> 672
>> > >>
>> > >
>> > >Jira Project has been created:
>> > >https://issues.apa

Re: [CRYPTO] Git repository requested

[Gangumalla, Uma]

Hi Benedikt,

 Here is my username: umamaheswararao

Regards,
Uma

On 4/14/16, 5:55 AM, "Benedikt Ritter" <brit...@apache.org> wrote:

>Benedikt Ritter <brit...@apache.org> schrieb am Mi., 13. Apr. 2016 um
>11:09 Uhr:
>
>> Chen, Haifeng <haifeng.c...@intel.com> schrieb am Mi., 13. Apr. 2016 um
>> 05:18 Uhr:
>>
>>> The git repository for Apache Commons Crypto has been created. It is
>>> locked so commits won't be accepted for now, will inform Daniel when we
>>> want the lock lifted.
>>> https://git-wip-us.apache.org/repos/asf?p=commons-crypto.git
>>>
>>> Next we may need to setup a JIRA project and the initial committers.
>>> Thanks to Dianel, Benedikt, and Uma.
>>>
>>> - [DONE]vote for Chimera to join Apache Commons
>>> - [DONE]decide on a name for the new component (Apache Commons Crypto)
>>> - [DONE]move code to an Apache repo (probably git)
>>> - request a Jira project
>>>
>>
>> Request created:
>> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-11672
>>
>
>Jira Project has been created:
>https://issues.apache.org/jira/browse/CRYPTO/
>
>I need Uma's and Haifeng's jira user names to add them to the
>commons-developers group in Jira.
>
>Benedikt
>
>
>>
>>
>>> - setup maven build
>>> - setup project website
>>> - work on an initial release under Apache Commons coordinates
>>>
>>>
>>> -Original Message-
>>> From: Benedikt Ritter [mailto:brit...@apache.org]
>>> Sent: Monday, April 11, 2016 12:30 AM
>>> To: Commons Developers List <dev@commons.apache.org>
>>> Subject: Re: [CRYPTO] Git repository requested
>>>
>>> Hello,
>>>
>>> Gangumalla, Uma <uma.ganguma...@intel.com> schrieb am Sa., 9. Apr. 2016
>>> um
>>> 21:17 Uhr:
>>>
>>> > Ok. Intel should file CCLA for this? Or some management mail proof
>>> > should be sufficient?
>>> > Please let me know, based on that I would work on them to get it.
>>> >
>>>
>>> CCLA sounds good, but I'm not sure. Can anybody help?
>>>
>>> Benedikt
>>>
>>>
>>> >
>>> > Regards,
>>> > Uma
>>> >
>>> > On 4/9/16, 4:27 AM, "Benedikt Ritter" <brit...@apache.org> wrote:
>>> >
>>> > >Hi,
>>> > >
>>> > >Infra has responded [1]. I've created the new repository request
>>>with
>>> > >the "import initial code base"-option set to the chimera github
>>>repo.
>>> > >Infra now needs proof of the software grant by Intel.
>>> > >
>>> > >Uma, can you take care of this?
>>> > >
>>> > >Regards,
>>> > >Benedikt
>>> > >
>>> > >[1]
>>> > 
>>>>https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-11
>>> > >627
>>> > >
>>> > >Gangumalla, Uma <uma.ganguma...@intel.com> schrieb am Sa., 9. Apr.
>>> > >2016
>>> > um
>>> > >10:22 Uhr:
>>> > >
>>> > >> Great. Thanks a lot, Benedikt for taking forward. :-)
>>> > >>
>>> > >> Regards,
>>> > >> Uma
>>> > >>
>>> > >> On 4/9/16, 12:51 AM, "Benedikt Ritter" <brit...@apache.org> wrote:
>>> > >>
>>> > >> >Hi,
>>> > >> >
>>> > >> >I've just created a request for creating the crypto git
>>>repository
>>> [1].
>>> > >> >I'll keep you updated on the state of the request.
>>> > >> >
>>> > >> >Benedikt
>>> > >> >
>>> > >> >[1]
>>> > >>
>>> > >>>
>>> > 
>>>https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-116
>>> > 27
>>> > >>
>>> > >>
>>> > >> 
>>>---
>>> > >> -- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> > >> For additional commands, e-mail: dev-h...@commons.apache.org
>>> > >>
>>> > >>
>>> >
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> > For additional commands, e-mail: dev-h...@commons.apache.org
>>> >
>>> >
>>>
>>


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

Re: [CRYPTO] Git repository requested

[Gangumalla, Uma]

Ok. Intel should file CCLA for this? Or some management mail proof should
be sufficient?
Please let me know, based on that I would work on them to get it.

Regards,
Uma

On 4/9/16, 4:27 AM, "Benedikt Ritter" <brit...@apache.org> wrote:

>Hi,
>
>Infra has responded [1]. I've created the new repository request with the
>"import initial code base"-option set to the chimera github repo. Infra
>now
>needs proof of the software grant by Intel.
>
>Uma, can you take care of this?
>
>Regards,
>Benedikt
>
>[1] 
>https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-11627
>
>Gangumalla, Uma <uma.ganguma...@intel.com> schrieb am Sa., 9. Apr. 2016 um
>10:22 Uhr:
>
>> Great. Thanks a lot, Benedikt for taking forward. :-)
>>
>> Regards,
>> Uma
>>
>> On 4/9/16, 12:51 AM, "Benedikt Ritter" <brit...@apache.org> wrote:
>>
>> >Hi,
>> >
>> >I've just created a request for creating the crypto git repository [1].
>> >I'll keep you updated on the state of the request.
>> >
>> >Benedikt
>> >
>> >[1]
>> 
>>>https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-11627
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>


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

Re: [CRYPTO] Git repository requested

[Gangumalla, Uma]

Great. Thanks a lot, Benedikt for taking forward. :-)

Regards,
Uma

On 4/9/16, 12:51 AM, "Benedikt Ritter"  wrote:

>Hi,
>
>I've just created a request for creating the crypto git repository [1].
>I'll keep you updated on the state of the request.
>
>Benedikt
>
>[1] 
>https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-11627


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

Re: [DISCUSS][CHIMERA] Name for the new component

[Gangumalla, Uma]

Just collected all the proposed names here for tracking purpose at single
place:

Apache Commons Crypto
Apache Commons Crypto Libs
Apache Commons Crypto Extensions
Apache Commons AES
Apache Commons AES Libs
Apache Commons AES Extensions
Apache Commons Crypto Wrapper
Apache Commons Crypto Helper
Apache Commons EasyCrypt
Apache Commons FastCrypt
Apache Commons OpenSSL
Apache Commons OpenSSL Wrapper (contracted to Apache Commons OSW)



My preference order:
 1) Apache Commons Crypto
 2) Apache Commons FastCrypto
 3) Apache Commons OSW

Regards,
Uma


On 3/25/16, 7:04 AM, "Benedikt Ritter"  wrote:

>Hi,
>
>after we've accepted the Chimera project [1] as new Apache Commons
>project,
>it's time to decide on a name. I've used Apache Commons Crypto in the
>past,
>but some have argued that it isn't to the point.
>I'd like to find a name the same way we did it for the potential Math TLP.
>Just add your idea to this thread and we'll tally them up after the easter
>weekend. The name with the most nominations wins :-)
>Please remember that Apache Commons component names should be short and
>descriptive.
>
>Here are my proposals:
>
>Apache Commons Crypto
>Apache Commons Crypto Libs
>Apache Commons Crypto Extensions
>Apache Commons AES
>Apache Commons AES Libs
>Apache Commons AES Extensions
>
>Best regards and happy easter!
>Benedikt
>
>[1] https://github.com/intel-hadoop/chimera


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

Re: [VOTE] Accept Chimera as new Apache Commons Component

[Gangumalla, Uma]

>I am also worried about the JNI stuff, but I think a new group of
developers would be good for this community.
Thanks Oliver for your opinion.
Yes, handful of members in this below community are really very good at
JNI and Java. Also we would consider to explore on JNA stuff which was
asked/suggested by Gary.

Regards,
Uma

On 3/22/16, 11:22 AM, "Oliver Heger"  wrote:

>Since we already started to use fractional numbers, I would be +0.5.
>
>I am also worried about the JNI stuff, but I think a new group of
>developers would be good for this community.
>
>Oliver
>
>Am 21.03.2016 um 09:45 schrieb Benedikt Ritter:
>> Hi all,
>> 
>> after long discussions I think we have gathered enough information to
>> decide whether we want to accept the Chimera project as a new Apache
>> Commons component.
>> 
>> Proposed name: Apache Commons Crypto
>> Proposal text:
>> https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html
>> Initial Code Base:  https://github.com/intel-hadoop/chimera/
>> Initial Committers (Names in alphabetical order):
>> - Aaron T. Myers (a...@apache.org, Apache Hadoop PMC, one of the original
>> Crypto dev team in Apache Hadoop)
>> - Andrew Wang (w...@apache.org, Apache Hadoop PMC, one of the original
>> Crypto dev team in Apache Hadoop)
>> - Chris Nauroth (cnaur...@apache.org, Apache Hadoop PMC and active
>> reviewer)
>> - Colin P. McCabe (cmcc...@apache.org, Apache Hadoop PMC, one of the
>> original Crypto dev team in Apache Hadoop)
>> - Dapeng Sun (s...@apache.org, Apache Sentry Committer, Chimera
>>contributor)
>> - Dian Fu (dia...@apache.org, Apache Sqoop Committer, Chimera
>>contributor)
>> - Dong Chen (do...@apache.org, Apache Hive Committer,interested on
>>Chimera)
>> - Ferdinand Xu (x...@apache.org, Apache Hive Committer, Chimera
>>contributor)
>> - Haifeng Chen (haifengc...@apache.org, Chimera lead and code
>>contributor)
>> - Marcelo Vanzin (Apache Spark Committer, Chimera contributor)
>> - Uma Maheswara Rao G (umamah...@apache.org, Apache Hadoop PMC, One of
>>the
>> original Crypto dev/review team in Apache Hadoop)
>> - Yi Liu (y...@apache.org, Apache Hadoop PMC, One of the original Crypto
>> dev/review team in Apache Hadoop)
>> 
>> Please review the proposal and vote.
>> This vote will close no sooner than 72 hours from now, i.e. after 0900
>> GMT 24-Mar 2016
>> 
>>   [ ] +1 Accept Chimera as new Apache Commons Component
>>   [ ] +0 OK, but...
>>   [ ] -0 OK, but really should fix...
>>   [ ] -1 I oppose this because...
>> 
>> Thank you!
>> Benedikt
>> 
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org
>


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

Re: [VOTE] Accept Chimera as new Apache Commons Component

[Gangumalla, Uma]

+1 (non-binding)


+common-dev@hadoop
On 3/21/16, 6:59 PM, "Gangumalla, Uma" <uma.ganguma...@intel.com> wrote:

>+1 (non-binding)
>
>
>Regards,
>Uma
>
>On 3/21/16, 1:45 AM, "Benedikt Ritter" <brit...@apache.org> wrote:
>
>>Hi all,
>>
>>after long discussions I think we have gathered enough information to
>>decide whether we want to accept the Chimera project as a new Apache
>>Commons component.
>>
>>Proposed name: Apache Commons Crypto
>>Proposal text:
>>https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html
>>Initial Code Base:  https://github.com/intel-hadoop/chimera/
>>Initial Committers (Names in alphabetical order):
>>- Aaron T. Myers (a...@apache.org, Apache Hadoop PMC, one of the original
>>Crypto dev team in Apache Hadoop)
>>- Andrew Wang (w...@apache.org, Apache Hadoop PMC, one of the original
>>Crypto dev team in Apache Hadoop)
>>- Chris Nauroth (cnaur...@apache.org, Apache Hadoop PMC and active
>>reviewer)
>>- Colin P. McCabe (cmcc...@apache.org, Apache Hadoop PMC, one of the
>>original Crypto dev team in Apache Hadoop)
>>- Dapeng Sun (s...@apache.org, Apache Sentry Committer, Chimera
>>contributor)
>>- Dian Fu (dia...@apache.org, Apache Sqoop Committer, Chimera
>>contributor)
>>- Dong Chen (do...@apache.org, Apache Hive Committer,interested on
>>Chimera)
>>- Ferdinand Xu (x...@apache.org, Apache Hive Committer, Chimera
>>contributor)
>>- Haifeng Chen (haifengc...@apache.org, Chimera lead and code
>>contributor)
>>- Marcelo Vanzin (Apache Spark Committer, Chimera contributor)
>>- Uma Maheswara Rao G (umamah...@apache.org, Apache Hadoop PMC, One of
>>the
>>original Crypto dev/review team in Apache Hadoop)
>>- Yi Liu (y...@apache.org, Apache Hadoop PMC, One of the original Crypto
>>dev/review team in Apache Hadoop)
>>
>>Please review the proposal and vote.
>>This vote will close no sooner than 72 hours from now, i.e. after 0900
>>GMT 24-Mar 2016
>>
>>  [ ] +1 Accept Chimera as new Apache Commons Component
>>  [ ] +0 OK, but...
>>  [ ] -0 OK, but really should fix...
>>  [ ] -1 I oppose this because...
>>
>>Thank you!
>>Benedikt
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org
>


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

Re: [VOTE] Accept Chimera as new Apache Commons Component

[Gangumalla, Uma]

+1 (non-binding)


Regards,
Uma

On 3/21/16, 1:45 AM, "Benedikt Ritter"  wrote:

>Hi all,
>
>after long discussions I think we have gathered enough information to
>decide whether we want to accept the Chimera project as a new Apache
>Commons component.
>
>Proposed name: Apache Commons Crypto
>Proposal text:
>https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html
>Initial Code Base:  https://github.com/intel-hadoop/chimera/
>Initial Committers (Names in alphabetical order):
>- Aaron T. Myers (a...@apache.org, Apache Hadoop PMC, one of the original
>Crypto dev team in Apache Hadoop)
>- Andrew Wang (w...@apache.org, Apache Hadoop PMC, one of the original
>Crypto dev team in Apache Hadoop)
>- Chris Nauroth (cnaur...@apache.org, Apache Hadoop PMC and active
>reviewer)
>- Colin P. McCabe (cmcc...@apache.org, Apache Hadoop PMC, one of the
>original Crypto dev team in Apache Hadoop)
>- Dapeng Sun (s...@apache.org, Apache Sentry Committer, Chimera
>contributor)
>- Dian Fu (dia...@apache.org, Apache Sqoop Committer, Chimera contributor)
>- Dong Chen (do...@apache.org, Apache Hive Committer,interested on
>Chimera)
>- Ferdinand Xu (x...@apache.org, Apache Hive Committer, Chimera
>contributor)
>- Haifeng Chen (haifengc...@apache.org, Chimera lead and code contributor)
>- Marcelo Vanzin (Apache Spark Committer, Chimera contributor)
>- Uma Maheswara Rao G (umamah...@apache.org, Apache Hadoop PMC, One of the
>original Crypto dev/review team in Apache Hadoop)
>- Yi Liu (y...@apache.org, Apache Hadoop PMC, One of the original Crypto
>dev/review team in Apache Hadoop)
>
>Please review the proposal and vote.
>This vote will close no sooner than 72 hours from now, i.e. after 0900
>GMT 24-Mar 2016
>
>  [ ] +1 Accept Chimera as new Apache Commons Component
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this because...
>
>Thank you!
>Benedikt


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

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

Dear All,

Please find the proposal document text for Apache Commons Crypto project
below and the same has been committed at Chimera project home folder [1] .

Please provide your feedbacks and let me know if anything else need to
cover in this document.

Thanks a lot for the help and support so far.

[1]  https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html
<https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html>https://
github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html>





Proposal for Apache Commons Crypto Package

(0) Rationale

Providing Java based optimized and high performance cryptographic IO
streams for the applications who wants to implement the data encryption.
It also provides cipher level API to use. It does provide the openssl API
integration and provide the fallback mechanism to use JCE when openssl
library unavailable.
(Note: Please note that Commons Crypto doesn’t implement the cryptographic
algorithm such as AES directly. It wraps to Openssl or JCE which implement
algorithms.)

(1) Scope of the Package

This proposal is to create a package of cryptographic IO classes with the
integration of Openssl library.
It focuses on AES-NI optimizations mainly and it can be extended to other
algorithms based on demand from the users later.

(1.5) Interaction With Other Packages

Commons Crypto relies on standard JDK 7 (or later) APIs for production
deployment and on OpenSSL 1.0.1c devl libraries.
It utilizes the JUnit unit testing framework, but this is of interest only
to developers of the component.
The functionality provided by Commons Crypto is currently in use by Apache
Hadoop and Apache Spark, and both of those communities
have expressed interest in changing their dependency to be on the central
Commons Crypto package once it exists.

(2) Initial Source of the Package

The initial classes came from the Apache Hadoop.
The proposed package name for the new component is
org.apache.commons.crypto.

(3) Required Apache Commons Resources

* Git Repository - New repository commons-crypto
* Mailing List - Discussions will take place on the general
dev@commons.apache.org mailing list.
  To help list subscribers identify messages of interest, it is suggested
that the message subject of messages about this component be prefixed with
[Crypto].
* JIRA - New component "Crypto" under the "Commons" project.
* Confluence FAQ - New category "commons-crypto" (when available).

(4) Initial Committers (Names in alphabetical order)

* Aaron T. Myers (a...@apache.org, Apache Hadoop PMC, one of the original
Crypto dev team in Apache Hadoop)
* Andrew Wang (w...@apache.org, Apache Hadoop PMC, one of the original
Crypto dev team in Apache Hadoop)
* Chris Nauroth (cnaur...@apache.org, Apache Hadoop PMC and active
reviewer)
* Colin P. McCabe (cmcc...@apache.org, Apache Hadoop PMC, one of the
original Crypto dev team in Apache Hadoop)
* Dapeng Sun (s...@apache.org, Apache Sentry Committer, Chimera contributor)
* Dian Fu (dia...@apache.org, Apache Sqoop Committer, Chimera contributor)
* Dong Chen (do...@apache.org, Apache Hive Committer,interested on Chimera)
* Ferdinand Xu (x...@apache.org, Apache Hive Committer, Chimera contributor)
* Haifeng Chen (haifengc...@apache.org, Chimera lead and code contributor)
* Marcelo Vanzin (Apache Spark Committer, Chimera contributor)
* Uma Maheswara Rao G (umamah...@apache.org, Apache Hadoop PMC, One of the
original Crypto dev/review team in Apache Hadoop)
* Yi Liu (y...@apache.org, Apache Hadoop PMC, One of the original Crypto
dev/review team in Apache Hadoop)





Regards,
Uma

On 3/7/16, 5:20 PM, "Gangumalla, Uma" <uma.ganguma...@intel.com> wrote:

>Dear all, Sorry for the delay. Working out on the proposal document, we
>will get it posted here soon.
>
>Regards,
>Uma
>
>
>On 2/26/16, 1:26 PM, "Gary Gregory" <garydgreg...@gmail.com> wrote:
>
>>I take it the Crypto squared is a typo and that you wanted to close the
>>quote.
>>
>>G
>>
>>On Fri, Feb 26, 2016 at 12:47 PM, Gangumalla, Uma
>><uma.ganguma...@intel.com>
>>wrote:
>>
>>>
>>>Ok. Thanks Benedikt. We would get the proposal document ready soon.
>>>Also one question, shall we rename the package to org.apache.* in
>>>Chimera
>>>git project first before pushing the code to Apache Commons? Or we can
>>>work here once moved the code?
>>>What do you suggest? For making package rename, component name should be
>>>finalized I think.
>>>
>>>Does every one ok with "Apache Commons Crypto² ?
>>>
>>>Regards,
>>>Uma
>>>
>>>On 2/26/16, 5:11 AM, "Benedikt Ritter" <brit...@apache.org> wrote:
>>>
>>>>Okay, so I think the only thing missing before we start the
>>>integrat

Re: Request to add into Apache Commons Wiki contributors group

[Gangumalla, Uma]

Hi All,

Do we have proposal pages added into Wiki before? I am looking to add one
into Wiki, but I did not find any page created for proposals in Apache
Commons Wiki. 
I found existing proposals available in Commons site:
http://commons.apache.org/proper/commons-io/proposal.html
So, I wanted to check is it ok to create section in Apache Commons Wiki
for ³New Component Proposal² section and from there to proposals page? Or
we we track in commons site itself for the consistency?

Please some one confirm this for me.

Regards,
Uma

On 3/15/16, 2:00 PM, "Gangumalla, Uma" <uma.ganguma...@intel.com> wrote:

>Hi Stefan,
>
> Thanks a lot.
>
>Regards,
>Uma
>
>On 3/15/16, 12:57 PM, "Stefan Bodewig" <bode...@apache.org> wrote:
>
>>Hi Uma
>>
>>On 2016-03-15, Gangumalla, Uma wrote:
>>
>>> I would like to post Apache Commons Crypto proposal in Apache Commons
>>> Wiki page. For this could you please add me into Wiki contributors
>>> group?
>>
>>Should be done.
>>
>>Cheers
>>
>>Stefan
>>
>>-
>>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org
>


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

Re: Request to add into Apache Commons Wiki contributors group

[Gangumalla, Uma]

Hi Stefan,

 Thanks a lot.

Regards,
Uma

On 3/15/16, 12:57 PM, "Stefan Bodewig" <bode...@apache.org> wrote:

>Hi Uma
>
>On 2016-03-15, Gangumalla, Uma wrote:
>
>> I would like to post Apache Commons Crypto proposal in Apache Commons
>> Wiki page. For this could you please add me into Wiki contributors
>> group?
>
>Should be done.
>
>Cheers
>
>Stefan
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org
>


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

Request to add into Apache Commons Wiki contributors group

[Gangumalla, Uma]

Hi,

I would like to post Apache Commons Crypto proposal in Apache Commons Wiki 
page. For this could you please add me into Wiki contributors group?

user: umagangumalla

Regards,
Uma

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

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

Dear all, Sorry for the delay. Working out on the proposal document, we
will get it posted here soon.

Regards,
Uma


On 2/26/16, 1:26 PM, "Gary Gregory" <garydgreg...@gmail.com> wrote:

>I take it the Crypto squared is a typo and that you wanted to close the
>quote.
>
>G
>
>On Fri, Feb 26, 2016 at 12:47 PM, Gangumalla, Uma
><uma.ganguma...@intel.com>
>wrote:
>
>>
>> Ok. Thanks Benedikt. We would get the proposal document ready soon.
>> Also one question, shall we rename the package to org.apache.* in
>>Chimera
>> git project first before pushing the code to Apache Commons? Or we can
>> work here once moved the code?
>> What do you suggest? For making package rename, component name should be
>> finalized I think.
>>
>> Does every one ok with "Apache Commons Crypto² ?
>>
>> Regards,
>> Uma
>>
>> On 2/26/16, 5:11 AM, "Benedikt Ritter" <brit...@apache.org> wrote:
>>
>> >Okay, so I think the only thing missing before we start the
>>integration of
>> >the component is a PROPOSAL document, describing the scope of the
>> >component
>> >and a list of initial commiters/contributors.
>> >
>> >2016-02-26 3:24 GMT+01:00 Chen, Haifeng <haifeng.c...@intel.com>:
>> >
>> >> Come back to clear out the codebase and IP concerns.
>> >>
>> >> [Benedikt] I still have concerns about the IP, since this seems to
>>be an
>> >> Intel codebase.
>> >> I have checked this. Chimera was developed as Apache 2 License from
>> >>ground
>> >> up. Agree with Jochen that the license matters.
>> >> Internally, this was approved as part of larger open source efforts
>>on
>> >> Apache Hadoop and related projects in Intel. We have IP plan
>>considered
>> >>as
>> >> part the open source process.
>> >>
>> >> As to the codebase, such as the package name is com.intel prefixed,
>>it
>> >>was
>> >> technical decision when using com.intel.chimera as the package
>>prefix.
>> >>We
>> >> original planned to use org.apache.chimera prefix. But we found that
>>we
>> >> couldnot publish org.apache. grouped artifacts to maven central
>> >>repository,
>> >> which needs to somewhat ownership for org.apache domain.
>> >>
>> >> To resolve the codebase problem, once all things are ready from
>>Commons,
>> >> we rename in a branch. And the branched code can be copied into
>>Commons
>> >> github as final.
>> >>
>> >> Thanks,
>> >> Haifeng
>> >>
>> >>
>> >> -Original Message-
>> >> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
>> >> Sent: Wednesday, February 24, 2016 12:40 PM
>> >> To: Commons Developers List <dev@commons.apache.org>
>> >> Cc: common-...@hadoop.apache.org
>> >> Subject: RE: [crypto][chimera] Next steps
>> >>
>> >> >> The same should be there with Chimera/Apache Crypto.
>> >> Yes, current implementation will fallback to JCE Cipher if native is
>>not
>> >> available.
>> >>
>> >> [Uma] we would fix up IP issues if any sooner. If you see all the
>>code
>> >> file license header is with Apache License files.
>> >> The current repo and package structure there with name Intel. I will
>> >>check
>> >> with Haifeng on resolution of this.
>> >> I will work with this ASAP for clear this out.
>> >>
>> >> Thanks,
>> >> Haifeng
>> >>
>> >> -Original Message-
>> >> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
>> >> Sent: Wednesday, February 24, 2016 5:13 AM
>> >> To: Commons Developers List <dev@commons.apache.org>
>> >> Cc: common-...@hadoop.apache.org
>> >> Subject: Re: [crypto][chimera] Next steps
>> >>
>> >> Thanks all for the valuable feedbacks and discussions.
>> >> Here are my replies for some of the questions..
>> >> [Mark wrote]
>> >> It depends. I care less about the quality of the code than I do about
>> >>the
>> >> community that comes with it / forms around it. A strong community
>>can
>> >>fix
>> >> code issues. Great code can't save a weak community.
>> >> [uma] Nice point. Fully agreed to it.
>> >>
>>

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

Yup. Thanks Gary for noting it. I don’t mean it to be squared :-)

“Apache Commons Crypto”

Also package name to be org.apache.commons.

Regards,
Uma



>
>On 2/26/16, 1:26 PM, "Gary Gregory" <garydgreg...@gmail.com> wrote:
>
>>I take it the Crypto squared is a typo and that you wanted to close the
>>quote.
>>
>>G
>>
>>On Fri, Feb 26, 2016 at 12:47 PM, Gangumalla, Uma
>><uma.ganguma...@intel.com>
>>wrote:
>>
>>>
>>> Ok. Thanks Benedikt. We would get the proposal document ready soon.
>>> Also one question, shall we rename the package to org.apache.* in
>>>Chimera
>>> git project first before pushing the code to Apache Commons? Or we can
>>> work here once moved the code?
>>> What do you suggest? For making package rename, component name should
>>>be
>>> finalized I think.
>>>
>>> Does every one ok with "Apache Commons Crypto² ?
>>>
>>> Regards,
>>> Uma
>>>
>>> On 2/26/16, 5:11 AM, "Benedikt Ritter" <brit...@apache.org> wrote:
>>>
>>> >Okay, so I think the only thing missing before we start the
>>>integration of
>>> >the component is a PROPOSAL document, describing the scope of the
>>> >component
>>> >and a list of initial commiters/contributors.
>>> >
>>> >2016-02-26 3:24 GMT+01:00 Chen, Haifeng <haifeng.c...@intel.com>:
>>> >
>>> >> Come back to clear out the codebase and IP concerns.
>>> >>
>>> >> [Benedikt] I still have concerns about the IP, since this seems to
>>>be an
>>> >> Intel codebase.
>>> >> I have checked this. Chimera was developed as Apache 2 License from
>>> >>ground
>>> >> up. Agree with Jochen that the license matters.
>>> >> Internally, this was approved as part of larger open source efforts
>>>on
>>> >> Apache Hadoop and related projects in Intel. We have IP plan
>>>considered
>>> >>as
>>> >> part the open source process.
>>> >>
>>> >> As to the codebase, such as the package name is com.intel prefixed,
>>>it
>>> >>was
>>> >> technical decision when using com.intel.chimera as the package
>>>prefix.
>>> >>We
>>> >> original planned to use org.apache.chimera prefix. But we found that
>>>we
>>> >> couldnot publish org.apache. grouped artifacts to maven central
>>> >>repository,
>>> >> which needs to somewhat ownership for org.apache domain.
>>> >>
>>> >> To resolve the codebase problem, once all things are ready from
>>>Commons,
>>> >> we rename in a branch. And the branched code can be copied into
>>>Commons
>>> >> github as final.
>>> >>
>>> >> Thanks,
>>> >> Haifeng
>>> >>
>>> >>
>>> >> -Original Message-
>>> >> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
>>> >> Sent: Wednesday, February 24, 2016 12:40 PM
>>> >> To: Commons Developers List <dev@commons.apache.org>
>>> >> Cc: common-...@hadoop.apache.org
>>> >> Subject: RE: [crypto][chimera] Next steps
>>> >>
>>> >> >> The same should be there with Chimera/Apache Crypto.
>>> >> Yes, current implementation will fallback to JCE Cipher if native is
>>>not
>>> >> available.
>>> >>
>>> >> [Uma] we would fix up IP issues if any sooner. If you see all the
>>>code
>>> >> file license header is with Apache License files.
>>> >> The current repo and package structure there with name Intel. I will
>>> >>check
>>> >> with Haifeng on resolution of this.
>>> >> I will work with this ASAP for clear this out.
>>> >>
>>> >> Thanks,
>>> >> Haifeng
>>> >>
>>> >> -Original Message-
>>> >> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
>>> >> Sent: Wednesday, February 24, 2016 5:13 AM
>>> >> To: Commons Developers List <dev@commons.apache.org>
>>> >> Cc: common-...@hadoop.apache.org
>>> >> Subject: Re: [crypto][chimera] Next steps
>>> >>
>>> >> Thanks all for the valuable feedbacks and discussions.
>>> 

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

Ok. Thanks Benedikt. We would get the proposal document ready soon.
Also one question, shall we rename the package to org.apache.* in Chimera
git project first before pushing the code to Apache Commons? Or we can
work here once moved the code?
What do you suggest? For making package rename, component name should be
finalized I think. 

Does every one ok with "Apache Commons Crypto² ?

Regards,
Uma 

On 2/26/16, 5:11 AM, "Benedikt Ritter" <brit...@apache.org> wrote:

>Okay, so I think the only thing missing before we start the integration of
>the component is a PROPOSAL document, describing the scope of the
>component
>and a list of initial commiters/contributors.
>
>2016-02-26 3:24 GMT+01:00 Chen, Haifeng <haifeng.c...@intel.com>:
>
>> Come back to clear out the codebase and IP concerns.
>>
>> [Benedikt] I still have concerns about the IP, since this seems to be an
>> Intel codebase.
>> I have checked this. Chimera was developed as Apache 2 License from
>>ground
>> up. Agree with Jochen that the license matters.
>> Internally, this was approved as part of larger open source efforts on
>> Apache Hadoop and related projects in Intel. We have IP plan considered
>>as
>> part the open source process.
>>
>> As to the codebase, such as the package name is com.intel prefixed, it
>>was
>> technical decision when using com.intel.chimera as the package prefix.
>>We
>> original planned to use org.apache.chimera prefix. But we found that we
>> couldnot publish org.apache. grouped artifacts to maven central
>>repository,
>> which needs to somewhat ownership for org.apache domain.
>>
>> To resolve the codebase problem, once all things are ready from Commons,
>> we rename in a branch. And the branched code can be copied into Commons
>> github as final.
>>
>> Thanks,
>> Haifeng
>>
>>
>> -Original Message-
>> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
>> Sent: Wednesday, February 24, 2016 12:40 PM
>> To: Commons Developers List <dev@commons.apache.org>
>> Cc: common-...@hadoop.apache.org
>> Subject: RE: [crypto][chimera] Next steps
>>
>> >> The same should be there with Chimera/Apache Crypto.
>> Yes, current implementation will fallback to JCE Cipher if native is not
>> available.
>>
>> [Uma] we would fix up IP issues if any sooner. If you see all the code
>> file license header is with Apache License files.
>> The current repo and package structure there with name Intel. I will
>>check
>> with Haifeng on resolution of this.
>> I will work with this ASAP for clear this out.
>>
>> Thanks,
>> Haifeng
>>
>> -Original Message-
>> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
>> Sent: Wednesday, February 24, 2016 5:13 AM
>> To: Commons Developers List <dev@commons.apache.org>
>> Cc: common-...@hadoop.apache.org
>> Subject: Re: [crypto][chimera] Next steps
>>
>> Thanks all for the valuable feedbacks and discussions.
>> Here are my replies for some of the questions..
>> [Mark wrote]
>> It depends. I care less about the quality of the code than I do about
>>the
>> community that comes with it / forms around it. A strong community can
>>fix
>> code issues. Great code can't save a weak community.
>> [uma] Nice point. Fully agreed to it.
>>
>>
>> [Jochen wrote]
>> Therefore, I suggest that you provide at least fallback implementations
>>in
>> pure Java, which are being used, if the JNI based stuff is not available
>> (for whatever reason).
>> [Uma] Thank you for the suggestion Jochen, If I understand your point
>> right,  Yes its there in Hadoop when we develop.
>> Here is the JIRA HADOOP-10735 : Fall back AesCtrCryptoCodec
>>implementation
>> from OpenSSL to JCE if non native support.
>>
>> The same should be there with Chimera/Apache Crypto.
>>
>>
>> [Benedikt]
>> I still have concerns about the IP, since this seems to be an Intel
>> codebase. I do not have the necessary experience to say what would be
>>the
>> right way here. My gut feeling tells me, that we should go through the
>> incubator. WDYT?
>> And [Jochen wrote]
>> "An Intel codebase" is not a problem as such. Question is: "Available
>> under what license?"
>>
>> [Uma] we would fix up IP issues if any sooner. If you see all the code
>> file license header is with Apache License files.
>> The current repo and package structure there with name Intel. I will
>>check
>> with Haifeng on

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

Thanks all for the valuable feedbacks and discussions.
Here are my replies for some of the questions..
[Mark wrote]
It depends. I care less about the quality of the code than I do about
the community that comes with it / forms around it. A strong community
can fix code issues. Great code can't save a weak community.
[uma] Nice point. Fully agreed to it.


[Jochen wrote]
Therefore, I suggest that you provide at least fallback
implementations in pure Java, which are being used, if the JNI based
stuff is not available (for whatever reason).
[Uma] Thank you for the suggestion Jochen, If I understand your point
right,  Yes its there in Hadoop when we develop.
Here is the JIRA HADOOP-10735 : Fall back AesCtrCryptoCodec implementation
from OpenSSL to JCE if non native support.

The same should be there with Chimera/Apache Crypto.


[Benedikt]
I still have concerns about the IP, since this seems to be an Intel
codebase. I do not have the necessary experience to say what would be the
right way here. My gut feeling tells me, that we should go through the
incubator. WDYT?
And [Jochen wrote]
"An Intel codebase" is not a problem as such. Question is: "Available
under what license?"

[Uma] we would fix up IP issues if any sooner. If you see all the code
file license header is with Apache License files.
The current repo and package structure there with name Intel. I will check
with Haifeng on resolution of this.


[Jochen wrote]
So, have the Chimera project attempt to resolve them quickly. If
possible: Fine. If not: We still have the Incubator as a possibility.
[Uma] Agree. We would resolve on this points in sooner.


Regards,
Uma

 
On 2/23/16, 1:18 AM, "Mark Thomas"  wrote:

>On 23/02/2016 09:12, sebb wrote:
>> On 23 February 2016 at 07:34, Benedikt Ritter 
>>wrote:
>>> I'm confused. None of the other PMC members has expressed whether he
>>>or she
>>> want's the see Chimera/crypto joining Apache Commons, yet we're already
>>> discussing how JNI bindings should be handled.
>>>
>>> I'd like to see:
>>> 1) a clear statement whether Chimera/crypto should become part of
>>>Apache
>>> Commons. Do we need a vote for that?
>> 
>> Yes, of course.
>> 
>> However that decision clearly depends on at least some of the design
>> aspects of the code.
>> If it were written entirely in C or Fortran, it would not be a
>> suitable candidate.
>> 
>>> 2) Discuss a plan on how to do that (I've described a possible plan
>>>[1])
>>> 3) After that is clear: discuss design details regarding the component.
>> 
>> Some design details impact on the decision.
>> 
>> Indeed even for pure Java code the code quality has a bearing on
>> whether Commons would/could want to take it.
>> Would we want a large code base with no unit-tests, no build
>> mechanism, and no comments?
>
>It depends. I care less about the quality of the code than I do about
>the community that comes with it / forms around it. A strong community
>can fix code issues. Great code can't save a weak community.
>
>How about creating a new sandbox component, let folks start work and see
>how the community develops?
>
>Mark
>
>
>> 
>>> Thanks! :-)
>>> Benedikt
>>>
>>> [1] http://markmail.org/message/74j4el6bpfpt4evs
>>>
>>> 2016-02-23 3:03 GMT+01:00 Xu, Cheng A :
>>>
 At this point, it has just Java interfaces only.

 -Original Message-
 From: Colin P. McCabe [mailto:cmcc...@apache.org]
 Sent: Tuesday, February 23, 2016 1:29 AM
 To: Hadoop Common
 Cc: Commons Developers List
 Subject: Re: [crypto][chimera] Next steps

 I would highly recommend shading this library when it is used in
 Hadoop and/or Spark, to prevent version skew problems between Hadoop
 and Spark like we have had in the past.

 What is the strategy for handling JNI components?  I think at a
 minimum, we should include the version number in the native library
 name to avoid problems when deploying multiple versions of Chimera.
 This is something that has been problematic in Hadoop with
 libhadoop.so.

 Is this library going to have Scala interfaces as well as Java ones,
 or just Java?

 cheers,
 Colin

 On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter 
 wrote:
> Hi,
>
> I'd like to discuss the next steps for moving the Chimera component
>to
> Apache Commons. So far, none of the other PMC members has expressed
>his
 or
> her thoughts about this. If nobody brings up objections about moving
>the
> component to Apache Commons, I'm assuming lazy consensus about this.
>
> So the next steps would be:
> - decide on a name for the new component (my proposal was Apache
>Commons
> Crypto)
> - move code to an Apache repo (probably git?!)
> - request a Jira project
> - setup maven build
> - setup project website
> - work on an initial release under Apache Commons 

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

>All files should follow the Commons Maven naming scheme to make it easy to
>reach from Maven, Ivy and so on.
>This will be commons-crypto-1.0.jar for example.
Sure. Thanks Gary. We will follow the naming convention here from Commons.

Regards,
Uma

On 2/22/16, 1:20 PM, "Gary Gregory" <garydgreg...@gmail.com> wrote:

>All files should follow the Commons Maven naming scheme to make it easy to
>reach from Maven, Ivy and so on.
>
>This will be commons-crypto-1.0.jar for example.
>
>Gary
>
>On Mon, Feb 22, 2016 at 1:06 PM, Gangumalla, Uma
><uma.ganguma...@intel.com>
>wrote:
>
>> >I would highly recommend shading this library when it is used in
>> Hadoop and/or Spark, to prevent version skew problems between Hadoop
>> and Spark like we have had in the past.
>> [uma]Ha. This avoids multiple jars versions issues. Agreed IMO.
>>
>> >I think at a
>> minimum, we should include the version number in the native library
>> name to avoid problems when deploying multiple versions of Chimera.
>> This is something that has been problematic in Hadoop with
>> libhadoop.so.
>> [uma]I think this is very valid suggestion. We can maintain version
>>number
>> with native lib. Also here target is to bundle libchimera.so along with
>> jars. Ideally it should be less confusion, but its good idea to have
>> version number along.
>>
>> >Is this library going to have Scala interfaces as well as Java ones,
>> or just Java?
>> [uma] Currently it is focussing on java. If there is a demand for Scala
>> specifically may be we can think on that.
>>
>> Regards,
>> Uma
>>
>> On 2/22/16, 9:28 AM, "Colin P. McCabe" <cmcc...@apache.org> wrote:
>>
>> >I would highly recommend shading this library when it is used in
>> >Hadoop and/or Spark, to prevent version skew problems between Hadoop
>> >and Spark like we have had in the past.
>> >
>> >What is the strategy for handling JNI components?  I think at a
>> >minimum, we should include the version number in the native library
>> >name to avoid problems when deploying multiple versions of Chimera.
>> >This is something that has been problematic in Hadoop with
>> >libhadoop.so.
>> >
>> >Is this library going to have Scala interfaces as well as Java ones,
>> >or just Java?
>> >
>> >cheers,
>> >Colin
>> >
>> >On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter <brit...@apache.org>
>> >wrote:
>> >> Hi,
>> >>
>> >> I'd like to discuss the next steps for moving the Chimera component
>>to
>> >> Apache Commons. So far, none of the other PMC members has expressed
>>his
>> >>or
>> >> her thoughts about this. If nobody brings up objections about moving
>>the
>> >> component to Apache Commons, I'm assuming lazy consensus about this.
>> >>
>> >> So the next steps would be:
>> >> - decide on a name for the new component (my proposal was Apache
>>Commons
>> >> Crypto)
>> >> - move code to an Apache repo (probably git?!)
>> >> - request a Jira project
>> >> - setup maven build
>> >> - setup project website
>> >> - work on an initial release under Apache Commons coordinates
>> >>
>> >> Anything missing?
>> >>
>> >> Regards,
>> >> Benedikt
>> >>
>> >> --
>> >> http://home.apache.org/~britter/
>> >> http://twitter.com/BenediktRitter
>> >> http://github.com/britter
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
>-- 
>E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>Java Persistence with Hibernate, Second Edition
><http://www.manning.com/bauer3/>
>JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>Spring Batch in Action <http://www.manning.com/templier/>
>Blog: http://garygregory.wordpress.com
>Home: http://garygregory.com/
>Tweet! http://twitter.com/GaryGregory


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

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

>I would highly recommend shading this library when it is used in
Hadoop and/or Spark, to prevent version skew problems between Hadoop
and Spark like we have had in the past.
[uma]Ha. This avoids multiple jars versions issues. Agreed IMO.

>I think at a
minimum, we should include the version number in the native library
name to avoid problems when deploying multiple versions of Chimera.
This is something that has been problematic in Hadoop with
libhadoop.so.
[uma]I think this is very valid suggestion. We can maintain version number
with native lib. Also here target is to bundle libchimera.so along with
jars. Ideally it should be less confusion, but its good idea to have
version number along.

>Is this library going to have Scala interfaces as well as Java ones,
or just Java?
[uma] Currently it is focussing on java. If there is a demand for Scala
specifically may be we can think on that.

Regards,
Uma

On 2/22/16, 9:28 AM, "Colin P. McCabe"  wrote:

>I would highly recommend shading this library when it is used in
>Hadoop and/or Spark, to prevent version skew problems between Hadoop
>and Spark like we have had in the past.
>
>What is the strategy for handling JNI components?  I think at a
>minimum, we should include the version number in the native library
>name to avoid problems when deploying multiple versions of Chimera.
>This is something that has been problematic in Hadoop with
>libhadoop.so.
>
>Is this library going to have Scala interfaces as well as Java ones,
>or just Java?
>
>cheers,
>Colin
>
>On Sat, Feb 20, 2016 at 3:15 AM, Benedikt Ritter 
>wrote:
>> Hi,
>>
>> I'd like to discuss the next steps for moving the Chimera component to
>> Apache Commons. So far, none of the other PMC members has expressed his
>>or
>> her thoughts about this. If nobody brings up objections about moving the
>> component to Apache Commons, I'm assuming lazy consensus about this.
>>
>> So the next steps would be:
>> - decide on a name for the new component (my proposal was Apache Commons
>> Crypto)
>> - move code to an Apache repo (probably git?!)
>> - request a Jira project
>> - setup maven build
>> - setup project website
>> - work on an initial release under Apache Commons coordinates
>>
>> Anything missing?
>>
>> Regards,
>> Benedikt
>>
>> --
>> http://home.apache.org/~britter/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter


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

Re: [crypto][chimera] Next steps

[Gangumalla, Uma]

Hi Benedikt,

 Thank you for the Next steps discussion. I thought of pinging you on this
:-)
  
 Here I would like to introduce Haifeng, who lead the efforts in Chimera
github project. 
 
I think Apache Commons Crypto looks good and self descriptive IMO.
 I am +1

Me and Haifeng had some discussion yesterday for the list to get commit
prevs. May be he could probably get list. Then I think Commons PMC can
make a decision on it.


>move code to an Apache repo (probably git?!)
+1 for git

>- setup maven build
If this point is just about maven build alone, then we should set up
Jenkins CI build boat as well right, may be we can add this point?

Regards,
Uma 

On 2/20/16, 8:29 AM, "Gary Gregory"  wrote:

>Who are the committers comming along for this component?
>
>Do we have enough of them?
>
>I like Apache Commons Crypto.
>
>Gary
>On Feb 20, 2016 3:15 AM, "Benedikt Ritter"  wrote:
>
>> Hi,
>>
>> I'd like to discuss the next steps for moving the Chimera component to
>> Apache Commons. So far, none of the other PMC members has expressed his
>>or
>> her thoughts about this. If nobody brings up objections about moving the
>> component to Apache Commons, I'm assuming lazy consensus about this.
>>
>> So the next steps would be:
>> - decide on a name for the new component (my proposal was Apache Commons
>> Crypto)
>> - move code to an Apache repo (probably git?!)
>> - request a Jira project
>> - setup maven build
>> - setup project website
>> - work on an initial release under Apache Commons coordinates
>>
>> Anything missing?
>>
>> Regards,
>> Benedikt
>>
>> --
>> http://home.apache.org/~britter/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>>


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

Re: Chimera as new component in Apache Commons

[Gangumalla, Uma]

Hi Benedikt,

Thanks for offering the great help.

Benedikt Wrote:

I'm no crypto expert but I can help with the Apache Commons related tasks,
like moving the code over to Apache Commons, setting up the maven build,
publishing the project website etc.
[UMA] Thank you. We would love to work with you on the further steps,
based on your guidance on these aspects.

Benedikt Wrote:

I'd love see you moving Chimera here.

[UMA] Thanks for the acceptance. :-)

Benedikt Wrote:

1. There are no Apache  sub communities. There is only the
Apache Commons community. This means, there won't be a separat mailing list
for the new component. It is important to understand that we are a
community maintaining a number of components. Not a group of sub
communities.
[UMA] Got it. Thanks for the information.


Benedikt Wrote:

2. The Apache Commons versioning guide lines are very restrictive [1]. We
put great effort into binary compatibility. This is, because we expect our
components to be reused by a lot of other projects and we try our best to
avoid jar hell. Often this means, that greater refactorings simply can not
be implemented since they would break BC. This is usually not a problem for
the major components. But it my be a problem for a young component.
[UMA] Right. 


Benedikt Wrote:

3. Apache Commons components usually have a (boring) descriptive name,
rather then a fancy one. This is the reason why we renamed Apache Commons
Sanselan zu Apache Commons Imaging. People should be able to tell just by
looking at the name of a component what that component is about. IMHO
Chimera falls into the fancy name category, so maybe we will discuss that
Name.
[UMA] Ok. Naming can be self descriptive. No issues on this.

Regards,
Uma (An Apache Hadoop PMC member)





On 2/16/16, 11:56 PM, "Benedikt Ritter" <brit...@apache.org> wrote:

>Hello Uma,
>
>welcome to the Apache Commons dev list. It's great to see that two
>projects
>get together to share code via Apache Commons.
>
>2016-02-16 22:36 GMT+01:00 Gangumalla, Uma <uma.ganguma...@intel.com>:
>
>> Hi Devs,
>>
>>
>>
>> Recently we worked with Spark community to implement the shuffle
>> encryption. While implementing that, we realized some/most of the code
>>in
>> Apache Hadoop encryption code and this implementation code have to be
>> duplicated. This leads to an idea to create separate reusable library,
>> named it as Chimera (https://github.com/intel-hadoop/chimera). It is an
>> optimized cryptographic library. It provides Java API for both cipher
>>level
>> and Java stream level to help developers implement high performance AES
>> encryption/decryption with the minimum code and effort.
>>
>>
>>
>> We know that Java has Cipher implementations, but why we need this
>> optimized cryptographic library:
>>
>> 1. Performance is very critical for encryption and decryption. The JDK
>> Cipher implementation of AES are not yet optimized with the modern
>> hardware. For example, the optimized implementation is 17x+ faster than
>> JDK6 implementations for some modes such as CBC decryption, CTR and GCM.
>> Even some optimizations has included JDK7 or JDK8, there are still 5x
>>to 6x
>> gap with the most optimized implementations.
>>
>
>That sounds pretty useful! :-)
>
>
>>
>> 2. Java Stream based API on cryptographic data stream. Cipher API is
>> powerful but a lot of code needs to be written for layered stream
>> processing applications. The design pattern is very common in modern
>> applications such as Hadoop or Spark.
>>
>>
>>
>> Chimera was originally based Hadoop crypto code but was improved and
>> generalized a lot for supporting wider scope of data encryption needs
>>for
>> more components in the community. The encryption related code in Hadoop
>>was
>> developed a year and so far it is running well. So we feel that code
>>part
>> of stable enough already.
>>
>>
>>
>> So, we propose to contribute this Chimera (optimized encryption library)
>> code to Apache Commons and we wanted to have independent release cycles
>>for
>> this module like any other modules in Apache Commons. This module is
>> basically provides Java based interfaces for encryption based IO and It
>> will have native based AES-NI encryption integration code.
>>
>>
>>
>> We already discussed about this proposal in Apache Hadoop dev lists and
>> the discussion conclusion was positive to contribute this module to
>>Apache
>> Commons.
>>
>>
>>
>> We need your help and support in adopting this code to make as Apache
>> Commons sub module and establish for making it to have its own

Chimera as new component in Apache Commons

[Gangumalla, Uma]

Hi Devs,



Recently we worked with Spark community to implement the shuffle encryption. 
While implementing that, we realized some/most of the code in Apache Hadoop 
encryption code and this implementation code have to be duplicated. This leads 
to an idea to create separate reusable library, named it as Chimera 
(https://github.com/intel-hadoop/chimera). It is an optimized cryptographic 
library. It provides Java API for both cipher level and Java stream level to 
help developers implement high performance AES encryption/decryption with the 
minimum code and effort.



We know that Java has Cipher implementations, but why we need this optimized 
cryptographic library:

1. Performance is very critical for encryption and decryption. The JDK Cipher 
implementation of AES are not yet optimized with the modern hardware. For 
example, the optimized implementation is 17x+ faster than JDK6 implementations 
for some modes such as CBC decryption, CTR and GCM. Even some optimizations has 
included JDK7 or JDK8, there are still 5x to 6x gap with the most optimized 
implementations.

2. Java Stream based API on cryptographic data stream. Cipher API is powerful 
but a lot of code needs to be written for layered stream processing 
applications. The design pattern is very common in modern applications such as 
Hadoop or Spark.



Chimera was originally based Hadoop crypto code but was improved and 
generalized a lot for supporting wider scope of data encryption needs for more 
components in the community. The encryption related code in Hadoop was 
developed a year and so far it is running well. So we feel that code part of 
stable enough already.



So, we propose to contribute this Chimera (optimized encryption library) code 
to Apache Commons and we wanted to have independent release cycles for this 
module like any other modules in Apache Commons. This module is basically 
provides Java based interfaces for encryption based IO and It will have native 
based AES-NI encryption integration code.



We already discussed about this proposal in Apache Hadoop dev lists and the 
discussion conclusion was positive to contribute this module to Apache Commons.



We need your help and support in adopting this code to make as Apache Commons 
sub module and establish for making it to have its own development community 
(of course we can discuss more about this factors in this thread). And Hadoop 
and Spark will be the two visible projects to use it. We do expect there will 
be more projects using it.



Once Apache Commons PMC agreed to place this module under Commons, I will work 
on getting the interested developers etc for establishing Chimera development 
community as part of next steps. Please help on the process.



Regards,

Uma (An Apache Hadoop PMC member)

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