commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gangumalla, Uma" <uma.ganguma...@intel.com>
Subject Re: [crypto][chimera] Next steps
Date Mon, 22 Feb 2016 21:26:26 GMT

>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" <garydgregory@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.gangumalla@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" <cmccabe@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 <britter@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>-- 
>E-Mail: garydgregory@gmail.com | ggregory@apache.org
>Java Persistence with Hibernate, Second Edition
><http://www.manning.com/bauer3/>
>JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>Spring Batch in Action <http://www.manning.com/templier/>
>Blog: http://garygregory.wordpress.com
>Home: http://garygregory.com/
>Tweet! http://twitter.com/GaryGregory


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


Mime
View raw message