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.<component name> 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. >>> >> >>> >> >>> >> [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" <ma...@apache.org> wrote: >>> >> >>> >> >On 23/02/2016 09:12, sebb wrote: >>> >> >> On 23 February 2016 at 07:34, Benedikt Ritter >>><brit...@apache.org> >>> >> >>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 <cheng.a...@intel.com>: >>> >> >>> >>> >> >>>> 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 >>> >> >>>> <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 >>> >> >>>> >>> >> >>>> >>> >> >>> >>> >> >>> >>> >> >>> -- >>> >> >>> 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 >>> >> >> >>> >> > >>> >> > >>> >> >>>>--------------------------------------------------------------------- >>> >> >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 >>> >> >>> >> >>> >> >>>--------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> >> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >>> >> >>> > >>> > >>> >-- >>> >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 >