commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [crypto][chimera] Next steps
Date Mon, 22 Feb 2016 21:36:23 GMT
On Mon, Feb 22, 2016 at 1:26 PM, Gangumalla, Uma <uma.gangumalla@intel.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.
> Sure. Thanks Gary. We will follow the naming convention here from Commons.
>

For jar files, this will happen automatically if you follow the Commons
Maven conventions. For .dll and .so files, you/we'll have to adjust the
make files, unless there is a smarter way.

Gary


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


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message