Re: Any down sides to putting a controller service in the same package as a processor?

2018-09-25 Thread Mike Thomsen
Mark, Yeah, it already exists, but it is only used by the Mongo lookup service. Not going to push that change because it would invalidate the service completely, but I think it would be low impact for Mongo users. Mike On Tue, Sep 25, 2018 at 3:35 PM Mark Payne wrote: > Mike, > > The Mongo

Re: Any down sides to putting a controller service in the same package as a processor?

2018-09-25 Thread Mark Payne
Mike, The Mongo Controller Service already exists though, right? You cannot move it into the Processors NAR after it's already been released. That would change the 'bundle coordinates' for the controller service and would mean that any flow that uses it is no longer valid and would have to be

Re: Any down sides to putting a controller service in the same package as a processor?

2018-09-25 Thread Mike Thomsen
Thanks. That's what I thought. I may also do that for the Mongo package because it should cut some space by not duplicating the Mongo driver. On Tue, Sep 25, 2018 at 2:46 PM Bryan Bende wrote: > That is fine for the CS implementation, the CS API should be in it's own > NAR. > On Tue, Sep 25,

Re: Any down sides to putting a controller service in the same package as a processor?

2018-09-25 Thread Bryan Bende
That is fine for the CS implementation, the CS API should be in it's own NAR. On Tue, Sep 25, 2018 at 2:14 PM Mike Thomsen wrote: > > I picked up NIFI-5224, which is for creating a Solr client service, and was > wondering if there are any gotchas or down sides to putting the controller > service

Any down sides to putting a controller service in the same package as a processor?

2018-09-25 Thread Mike Thomsen
I picked up NIFI-5224, which is for creating a Solr client service, and was wondering if there are any gotchas or down sides to putting the controller service in the same NAR as the processors that will use it. Is there any reason I would want to avoid that? Thanks, Mike