Steven To Bryan's point if it will be best if you simply copy the code/base classes over to your Nar rather than extending from existing concrete implemented processors.
Thanks On Tue, Dec 26, 2017 at 1:50 PM, Byers, Steven K (Steve) CTR USARMY MEDCOM JMLFDC (US) <steven.k.byers....@mail.mil> wrote: > Bryan, > > We have extended a few processors from standard processors. For example, one > of the processors we are extending is: > org.apache.nifi.processors.standard.JmsConsumer > > In another processor we are importing > org.apache.nifi.processors.standard.util.JdbcCommon. > > I tried making the dependency on standard processors optional > (optional>true</optional>) which excludes the standard processors but then > NiFi won't start because those custom processors that depend on it cannot be > instantiated. > > > > Thank you, > > Steven K. Byers > DXC Technology - Contractor > Software Developer - Joint Medical Logistics Functional Development Center > (JMLFDC) > Defense Health Agency (DHA)/ Health Information Technology (HIT) Directorate/ > Solution Delivery Division (SDD)/Clinical Support Branch/JMLFDC > 1681 Nelson Street, Fort Detrick, MD 21702 > (443) 538-7575 | (410) 872-4923 > Email: steven.k.byers....@mail.mil > > > > -----Original Message----- > From: Bryan Bende [mailto:bbe...@gmail.com] > Sent: Tuesday, December 26, 2017 1:34 PM > To: dev@nifi.apache.org > Subject: Re: [Non-DoD Source] Re: Moving from version 1.1.2 to 1.4.0 > > Can you give some more details about what the dependency is for? > > If it is some utility code that exists in standard processors then we > should be looking to move that to other reusable modules so that you can > depend on it without depending on the processors. > > If it is because you extended a processor from standard processors, you > would probably want to just copy the processor code into your own NAR and > modify/extend it. > > On Tue, Dec 26, 2017 at 1:26 PM Byers, Steven K (Steve) CTR USARMY MEDCOM > JMLFDC (US) <steven.k.byers....@mail.mil> wrote: > >> Thanks for the reply, Bryan, >> >> Yes, two of our custom processors have a dependency on the standard >> processors. The dependency cannot be removed or those processors will not >> compile. >> >> Thank you, >> >> Steven K. Byers >> DXC Technology - Contractor >> Software Developer - Joint Medical Logistics Functional Development Center >> (JMLFDC) >> Defense Health Agency (DHA)/ Health Information Technology (HIT) >> Directorate/ Solution Delivery Division (SDD)/Clinical Support Branch/JMLFDC >> 1681 Nelson Street, Fort Detrick, MD 21702 >> (443) 538-7575 | (410) 872-4923 >> Email: steven.k.byers....@mail.mil >> >> >> >> -----Original Message----- >> From: Bryan Bende [mailto:bbe...@gmail.com] >> Sent: Tuesday, December 26, 2017 11:25 AM >> To: dev@nifi.apache.org >> Subject: [Non-DoD Source] Re: Moving from version 1.1.2 to 1.4.0 >> >> Hello, >> >> This means your custom NAR is bundling the standard processors jar and as >> a result they are getting discovered twice, once from your NAR and once >> from the standard NAR. >> >> You’ll have to look at your maven dependencies for your custom NARs and >> figure out why the dependency on standard processors exists and remove it. >> >> Thanks, >> >> Bryan >> >> >> On Tue, Dec 26, 2017 at 11:09 AM Byers, Steven K (Steve) CTR USARMY MEDCOM >> JMLFDC (US) <steven.k.byers....@mail.mil> wrote: >> >> > Hi devs, >> > >> > I'm looking into moving from NiFi 1.1.2 to 1.4.0. We have several >> > custom processors and services. Everything is compiling without any >> > problems but when I put the services into the 1.4.0 instance, NiFi >> > shows in the list of processors a 1.1.2 and 1.4.0 version of all >> > processors including the stock NiFi processors. If I just load our >> > custom processors that do not require a service, NiFi is fine and the >> > processor list looks like it should and the custom processors work >> > fine. It seems to be something related to the custom services. Is >> > there some documentation or any guidance someone can provide to assist >> > with what I am doing? >> > >> > Thank you, >> > >> > Steven K. Byers >> > DXC Technology - Contractor >> > Software Developer - Joint Medical Logistics Functional Development >> > Center >> > (JMLFDC) >> > Defense Health Agency (DHA)/ Health Information Technology (HIT) >> > Directorate/ Solution Delivery Division (SDD)/Clinical Support >> > Branch/JMLFDC >> > 1681 Nelson Street, Fort Detrick, MD 21702 >> > (443) 538-7575 | (410) 872-4923 >> > Email: steven.k.byers....@mail.mil >> > >> > >> > >> > -- >> Sent from Gmail Mobile >> > -- > Sent from Gmail Mobile
