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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to