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
