It would likely be easier to adapt to such an API change than developing/co-opting the protocol code, which would be throwaway work once there is a release anyway. Would be better to just manage with snapshot till there is a release. Or we could wait till there is a release. I can check with the devs if they have a plan to release a version soon.
On Wed, Jan 9, 2019 at 6:29 PM Vlad Rozov <vro...@apache.org> wrote: > It is not only hosting on Apache or Maven Central that worries me. It is > also a snapshot version. My experience with hosting artifacts on maven > servers that are not mirrored by Maven central and a dependency on a > snapshot version are equally bad and both usually lead to broken builds. > > While protocol may change, API of the connector may change as well, so you > are not well guarded here by using salesforce library, IMO. > > Thank you, > > Vlad > > > On Jan 9, 2019, at 16:57, Pramod Immaneni <pramod.imman...@gmail.com> > wrote: > > > > 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 > > -- Thanks, Pramod http://ts.la/pramod3443
