Snapshot dependency in third-party repo is a bit problematic as we had seen last year ;-)
But I would not consider it a blocker as long as the licensing is clear. On Wed, Jan 9, 2019 at 6:40 PM Pramod Immaneni <pramod.imman...@gmail.com> wrote: > 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 >
