Hey Ray, >From usability perspective, you are right, JVPP is not useful outside of VPP.
But on the other hand, VPP plugins are also not useful outside of VPP but they still get dedicated projects. Same applies for Honeycomb (the VPP specific distribution of HC at least), it is not useful without VPP. However, dedicated projects allow for separation of control and enable better control over the codebase. That's what we want for JVPP, we want better control out of this. Plus we think this would bring benefits to VPP project as well (as Marek mentioned). Another plus is that it will not require VPP committers to spend time reviewing/merging JVPP code, since that's what we(the devs of JVPP) should be doing. Currently, I'm aware of 2 language bindings on top of VPP's binary APIs: Python and Java. But in the future as new language bindings come, I don't think VPP should host all of them and all of their committers. Regards, Maros -----Original Message----- From: honeycomb-dev-boun...@lists.fd.io [mailto:honeycomb-dev-boun...@lists.fd.io] On Behalf Of Kinsella, Ray Sent: Wednesday, October 26, 2016 11:52 AM To: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) <mgrad...@cisco.com>; vpp-dev <vpp-dev@lists.fd.io>; honeycomb-dev <honeycomb-...@lists.fd.io> Cc: Ed Warnicke (eaw) <e...@cisco.com> Subject: Re: [honeycomb-dev] [vpp-dev] jVpp as independent fd.io project Hi Marek, I am not sure that jVpp is useful outside of VPP, So outside of helping with 1), I am not sure what the benefit would be. I would have to imagine 1) is fixable in some other way. Ray K On 26/10/2016 08:06, Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) wrote: > Hi, > > > > this is follow-up to the discussion started on the last VPP weekly meeting. > > > > In my opinion, the biggest advantages are: > > > > 1) it would make VPP build faster and more stable > > 2) it would make possible to use build system that supports dependency > management > > and hence is more suitable for java build (e.g. Maven or Gradle) > > Having 2) we could for example translate vpe.api to yang (messages as > RPCs), generate Java bindings (requires yangtools from ODL) > > and have NETCONF support in HC for all VPP APIs. > > > > The jVpp project could have two parts: > > - Java API generator that could be referenced from outside (e.g. > in form of a maven plugin) > > - actual API generation for all the plugins that live in VPP > codebase, > > other fd.io plugins (e.g. NSH) could be also included or use API generator. > > > > Regards, > > Marek > > > > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev > _______________________________________________ honeycomb-dev mailing list honeycomb-...@lists.fd.io https://lists.fd.io/mailman/listinfo/honeycomb-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
