Vlad, Not too worried about the dependency as the gating factor, it can always be hosted on some maven server. Importantly it is developed by salesforce folks who will handle the specifics, which will allow portability in case the protocol evolves. It also handles the sf replay protocol, reconnections and some login specific details that are helpful.
Thanks On Wed, Jan 9, 2019 at 4:08 PM Vlad Rozov <vro...@apache.org> wrote: > Pramod, > > Did you consider using CometD library directly? epm-connector is a thin > layer on top of CometD and skipping it will allow you at least to resolve > dependency on a snapshot version. > > Thank you, > > Vlad > > > On Jan 9, 2019, at 14:52, Thomas Weise <t...@apache.org> wrote: > > > > Thanks for the actionable input. > > > > I would suggest you try to contribute back. From my end I'm happy to > > support that as reviewer or in advisory capacity. > > > > If multiple folks maintaining private forks were to contribute back, the > > cost equation was more attractive (you benefit from other contributions > at > > the same time). That's how successful projects work (I happen to > contribute > > to couple of them). > > > > I think as part of that we will be able to identify and address perceived > > difficulties in contributions. > > > > There is still the issue that Apex in its current form is hard to adopt > > (when you put yourself into the shoes of someone who just uses the > binaries > > available here vs. some derivate of former support contract), but putting > > back enhancements and fixes developed as you go would be a good > > step forward. > > > > Thomas > > > > On Wed, Jan 9, 2019 at 2:35 PM Pramod Immaneni < > pramod.imman...@gmail.com> > > wrote: > > > >> We have a couple of operators notably a salesforce operator that I am > >> trying to get the necessary permissions at work to contribute. The > >> underlying salesforce client library (emp-connector) used by the > operator > >> doesn't have a release yet so that is another reason slowing things > down, > >> waiting to iron out issues. We are continuing to use apex and will > likely > >> produce more operators during this year. There is also a plan to go to > >> kubernetes and that would likely result in the port being contributed to > >> the community or work done in collaboration with community members in > the > >> open. > >> > >> While trying to do this, I am facing a hard time trying to convince my > >> superiors that it is worthwhile for the company to contribute. They like > >> the technology and apex is in the stack but question whether the > community > >> can work together and move forward, making their investment worthwhile. > >> They see discussions like this and others, where folks can't agree and > move > >> forward, especially those who have been working on it for a long time, > they > >> question if it is worth it. > >> > >> Thanks > >> > >> On Tue, Jan 8, 2019 at 10:17 PM Justin Mclean <jus...@classsoftware.com > > > >> wrote: > >> > >>> Hi, > >>> > >>> My understanding is that there was some active development in private > >>> forks? If any of that code could be contributed back here then that > could > >>> restate the project and generate interest. Does anyone know is that is > >> the > >>> case and if the people involved would be willing to do that? > >>> > >>> I do agrees 6 months without a commit is a long time. > >>> > >>> Thanks, > >>> Justin > >> > >> > >> > >> -- > >> Thanks, > >> Pramod > >> http://ts.la/pramod3443 > >> > > -- Thanks, Pramod http://ts.la/pramod3443
