You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Nicholas Deane <nd...@vitalimages.com> on 2018/01/09 16:47:36 UTC
Cross NAR Controller Service access with gradle
Hi,
I’m working on a custom processor and want to utilize NiFi’s SSLContextService.
In my build.gradle dependencies section, I’ve included:
compile "org.apache.nifi:nifi-ssl-context-service-api:$nifiVersion"
and in my code I’ve created the property descriptor with .identifiesControllerService(SSLContextService.class)
When I’m configuring the processor, I noticed that the property on the processor says that it “Requires Controller Service: SSLContextService from my-custom-nar”. When I create a StandardSSLContextService from the default org.apache.nifi bundle, it doesn’t show up in the processor’s list (as expected based on that info message).
I tried bringing in “nifi-ssl-context-service” and now I have two versions of StandardSSLContextService in the controller service list (one from the org.apache.nifi bundle and the other from my-custom-nar bundle). Is this how I should be doing something like this or is there a better way for me to use Controller Services across bundles and avoid having duplicates in that list?
Notice - Confidential Information The information in this communication and any attachments is strictly confidential and intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, any dissemination, distribution, copying or other use of the information contained in this communication and/or any attachment is strictly prohibited. If you have received this communication in error, please first notify the sender immediately and then delete this communication from all data storage devices and destroy all hard copies.
Re: Cross NAR Controller Service access with gradle
Posted by Matt Burgess <ma...@apache.org>.
Aw, man! I spent my lunch hour getting the Gradle stuff going, just to
learn there's already a plugin :) Thanks to @sponiro and to you for
sharing! I will take a look to make sure it's up to date, but if it
seems to be working for you, and you have access to the plugin through
public repos (jcenter/bintray, maven central, etc.) then we might be
better served with Pull Requests for any changes that are needed :)
Regards,
Matt
On Wed, Jan 10, 2018 at 3:34 PM, Nicholas Deane <nd...@vitalimages.com> wrote:
> Awesome. Thanks, Matt! I was missing the dependency on the nifi-standard-services-api-nar NAR. I spent some time looking things up and I came across the gradle nar plugin [1]
>
> Using that plugin, my build.gradle now contains the following lines:
>
> compile "org.apache.nifi:nifi-ssl-context-service-api:$nifiVersion"
> nar 'org.apache.nifi:nifi-standard-services-api-nar:1.4.0'
>
> Now when I build my custom nar, I can see that my processor requires the SSLContextService from nifi-standard-services-api-nar. The StandardSSLContextService from the default org.apache.nifi bundle shows up as selectable in that property and I’m able to get the processor started up with the SSLContext.
>
> [1] https://github.com/sponiro/gradle-nar-plugin
>
> Regards,
> Nicholas
>
> On 2018-01-10, 3:25 PM, "Matt Burgess" <ma...@apache.org> wrote:
>
> Nicholas,
>
> I finally had a few cycles to iron out some bugs in the Gradle NAR
> example [1], feel free to check it out as it should be in much better
> shape. Once it's ready for primetime, I'd like to add it to Lazybones
> [2] and/or find a home for it in nifi-maven [3] (or a new similar repo
> nifi-gradle ;)
>
> I'm going to try to apply this to an existing NAR in the NiFi codebase
> that does real work with third-party dependencies and parent NARs.
> Eventually I'd like to see it building equivalently and way faster
> than Maven :)
>
> Regards,
> Matt
>
> [1] https://github.com/mattyb149/nifi-gradle-nar-example
> [2] https://github.com/pledbrook/lazybones
> [3] https://github.com/apache/nifi-maven
>
> On Tue, Jan 9, 2018 at 12:06 PM, Matt Burgess <ma...@apache.org> wrote:
> > Nicholas,
> >
> > You shouldn't need to reference StandardSSLContextService explicitly,
> > as your processor should be using the interface SSLContextService
> > only. In the Maven world, this is done by bringing in
> > nifi-ssl-context-service-api as a "provided" dependency (not compile),
> > and adding a dependency on your NAR module to the
> > nifi-standard-services-api-nar NAR. This is handled by a custom
> > NarMojo for doing NiFi ARchive (NAR) packaging [1].
> >
> > In the Gradle world we'll need a task to do the same thing, I believe
> > it is mostly a matter of getting the separate subprojects set up to
> > mimic the Maven modules, and a task (whether published as a plugin
> > like the NarMojo plugin is for Maven or not) to update the NAR
> > manifest and such. I have begun work on this [2], please feel free to
> > take a look and let me know what you think. At present I believe I am
> > missing a directive to copy all the processors' subproject
> > dependencies into the NAR output artifact, I think I know how to fix
> > it (i.e. from project(':processors').tasks['jar'].archivePath) but
> > haven't had time to try it out.
> >
> > Please let me know if you'd like to work on the Gradle stuff together,
> > I would be happy to collaborate :)
> >
> > Regards,
> > Matt
> >
> > [1] https://github.com/apache/nifi-maven
> > [2] https://github.com/mattyb149/nifi-gradle-nar-example
> >
> > On Tue, Jan 9, 2018 at 11:47 AM, Nicholas Deane <nd...@vitalimages.com> wrote:
> >> Hi,
> >>
> >> I’m working on a custom processor and want to utilize NiFi’s SSLContextService.
> >>
> >> In my build.gradle dependencies section, I’ve included:
> >> compile "org.apache.nifi:nifi-ssl-context-service-api:$nifiVersion"
> >>
> >> and in my code I’ve created the property descriptor with .identifiesControllerService(SSLContextService.class)
> >>
> >> When I’m configuring the processor, I noticed that the property on the processor says that it “Requires Controller Service: SSLContextService from my-custom-nar”. When I create a StandardSSLContextService from the default org.apache.nifi bundle, it doesn’t show up in the processor’s list (as expected based on that info message).
> >>
> >> I tried bringing in “nifi-ssl-context-service” and now I have two versions of StandardSSLContextService in the controller service list (one from the org.apache.nifi bundle and the other from my-custom-nar bundle). Is this how I should be doing something like this or is there a better way for me to use Controller Services across bundles and avoid having duplicates in that list?
> >>
> >>
> >> Notice - Confidential Information The information in this communication and any attachments is strictly confidential and intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, any dissemination, distribution, copying or other use of the information contained in this communication and/or any attachment is strictly prohibited. If you have received this communication in error, please first notify the sender immediately and then delete this communication from all data storage devices and destroy all hard copies.
>
>
Re: Cross NAR Controller Service access with gradle
Posted by Nicholas Deane <nd...@vitalimages.com>.
Awesome. Thanks, Matt! I was missing the dependency on the nifi-standard-services-api-nar NAR. I spent some time looking things up and I came across the gradle nar plugin [1]
Using that plugin, my build.gradle now contains the following lines:
compile "org.apache.nifi:nifi-ssl-context-service-api:$nifiVersion"
nar 'org.apache.nifi:nifi-standard-services-api-nar:1.4.0'
Now when I build my custom nar, I can see that my processor requires the SSLContextService from nifi-standard-services-api-nar. The StandardSSLContextService from the default org.apache.nifi bundle shows up as selectable in that property and I’m able to get the processor started up with the SSLContext.
[1] https://github.com/sponiro/gradle-nar-plugin
Regards,
Nicholas
On 2018-01-10, 3:25 PM, "Matt Burgess" <ma...@apache.org> wrote:
Nicholas,
I finally had a few cycles to iron out some bugs in the Gradle NAR
example [1], feel free to check it out as it should be in much better
shape. Once it's ready for primetime, I'd like to add it to Lazybones
[2] and/or find a home for it in nifi-maven [3] (or a new similar repo
nifi-gradle ;)
I'm going to try to apply this to an existing NAR in the NiFi codebase
that does real work with third-party dependencies and parent NARs.
Eventually I'd like to see it building equivalently and way faster
than Maven :)
Regards,
Matt
[1] https://github.com/mattyb149/nifi-gradle-nar-example
[2] https://github.com/pledbrook/lazybones
[3] https://github.com/apache/nifi-maven
On Tue, Jan 9, 2018 at 12:06 PM, Matt Burgess <ma...@apache.org> wrote:
> Nicholas,
>
> You shouldn't need to reference StandardSSLContextService explicitly,
> as your processor should be using the interface SSLContextService
> only. In the Maven world, this is done by bringing in
> nifi-ssl-context-service-api as a "provided" dependency (not compile),
> and adding a dependency on your NAR module to the
> nifi-standard-services-api-nar NAR. This is handled by a custom
> NarMojo for doing NiFi ARchive (NAR) packaging [1].
>
> In the Gradle world we'll need a task to do the same thing, I believe
> it is mostly a matter of getting the separate subprojects set up to
> mimic the Maven modules, and a task (whether published as a plugin
> like the NarMojo plugin is for Maven or not) to update the NAR
> manifest and such. I have begun work on this [2], please feel free to
> take a look and let me know what you think. At present I believe I am
> missing a directive to copy all the processors' subproject
> dependencies into the NAR output artifact, I think I know how to fix
> it (i.e. from project(':processors').tasks['jar'].archivePath) but
> haven't had time to try it out.
>
> Please let me know if you'd like to work on the Gradle stuff together,
> I would be happy to collaborate :)
>
> Regards,
> Matt
>
> [1] https://github.com/apache/nifi-maven
> [2] https://github.com/mattyb149/nifi-gradle-nar-example
>
> On Tue, Jan 9, 2018 at 11:47 AM, Nicholas Deane <nd...@vitalimages.com> wrote:
>> Hi,
>>
>> I’m working on a custom processor and want to utilize NiFi’s SSLContextService.
>>
>> In my build.gradle dependencies section, I’ve included:
>> compile "org.apache.nifi:nifi-ssl-context-service-api:$nifiVersion"
>>
>> and in my code I’ve created the property descriptor with .identifiesControllerService(SSLContextService.class)
>>
>> When I’m configuring the processor, I noticed that the property on the processor says that it “Requires Controller Service: SSLContextService from my-custom-nar”. When I create a StandardSSLContextService from the default org.apache.nifi bundle, it doesn’t show up in the processor’s list (as expected based on that info message).
>>
>> I tried bringing in “nifi-ssl-context-service” and now I have two versions of StandardSSLContextService in the controller service list (one from the org.apache.nifi bundle and the other from my-custom-nar bundle). Is this how I should be doing something like this or is there a better way for me to use Controller Services across bundles and avoid having duplicates in that list?
>>
>>
>> Notice - Confidential Information The information in this communication and any attachments is strictly confidential and intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, any dissemination, distribution, copying or other use of the information contained in this communication and/or any attachment is strictly prohibited. If you have received this communication in error, please first notify the sender immediately and then delete this communication from all data storage devices and destroy all hard copies.
Re: Cross NAR Controller Service access with gradle
Posted by Matt Burgess <ma...@apache.org>.
Nicholas,
I finally had a few cycles to iron out some bugs in the Gradle NAR
example [1], feel free to check it out as it should be in much better
shape. Once it's ready for primetime, I'd like to add it to Lazybones
[2] and/or find a home for it in nifi-maven [3] (or a new similar repo
nifi-gradle ;)
I'm going to try to apply this to an existing NAR in the NiFi codebase
that does real work with third-party dependencies and parent NARs.
Eventually I'd like to see it building equivalently and way faster
than Maven :)
Regards,
Matt
[1] https://github.com/mattyb149/nifi-gradle-nar-example
[2] https://github.com/pledbrook/lazybones
[3] https://github.com/apache/nifi-maven
On Tue, Jan 9, 2018 at 12:06 PM, Matt Burgess <ma...@apache.org> wrote:
> Nicholas,
>
> You shouldn't need to reference StandardSSLContextService explicitly,
> as your processor should be using the interface SSLContextService
> only. In the Maven world, this is done by bringing in
> nifi-ssl-context-service-api as a "provided" dependency (not compile),
> and adding a dependency on your NAR module to the
> nifi-standard-services-api-nar NAR. This is handled by a custom
> NarMojo for doing NiFi ARchive (NAR) packaging [1].
>
> In the Gradle world we'll need a task to do the same thing, I believe
> it is mostly a matter of getting the separate subprojects set up to
> mimic the Maven modules, and a task (whether published as a plugin
> like the NarMojo plugin is for Maven or not) to update the NAR
> manifest and such. I have begun work on this [2], please feel free to
> take a look and let me know what you think. At present I believe I am
> missing a directive to copy all the processors' subproject
> dependencies into the NAR output artifact, I think I know how to fix
> it (i.e. from project(':processors').tasks['jar'].archivePath) but
> haven't had time to try it out.
>
> Please let me know if you'd like to work on the Gradle stuff together,
> I would be happy to collaborate :)
>
> Regards,
> Matt
>
> [1] https://github.com/apache/nifi-maven
> [2] https://github.com/mattyb149/nifi-gradle-nar-example
>
> On Tue, Jan 9, 2018 at 11:47 AM, Nicholas Deane <nd...@vitalimages.com> wrote:
>> Hi,
>>
>> I’m working on a custom processor and want to utilize NiFi’s SSLContextService.
>>
>> In my build.gradle dependencies section, I’ve included:
>> compile "org.apache.nifi:nifi-ssl-context-service-api:$nifiVersion"
>>
>> and in my code I’ve created the property descriptor with .identifiesControllerService(SSLContextService.class)
>>
>> When I’m configuring the processor, I noticed that the property on the processor says that it “Requires Controller Service: SSLContextService from my-custom-nar”. When I create a StandardSSLContextService from the default org.apache.nifi bundle, it doesn’t show up in the processor’s list (as expected based on that info message).
>>
>> I tried bringing in “nifi-ssl-context-service” and now I have two versions of StandardSSLContextService in the controller service list (one from the org.apache.nifi bundle and the other from my-custom-nar bundle). Is this how I should be doing something like this or is there a better way for me to use Controller Services across bundles and avoid having duplicates in that list?
>>
>>
>> Notice - Confidential Information The information in this communication and any attachments is strictly confidential and intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, any dissemination, distribution, copying or other use of the information contained in this communication and/or any attachment is strictly prohibited. If you have received this communication in error, please first notify the sender immediately and then delete this communication from all data storage devices and destroy all hard copies.
Re: Cross NAR Controller Service access with gradle
Posted by Matt Burgess <ma...@apache.org>.
Nicholas,
You shouldn't need to reference StandardSSLContextService explicitly,
as your processor should be using the interface SSLContextService
only. In the Maven world, this is done by bringing in
nifi-ssl-context-service-api as a "provided" dependency (not compile),
and adding a dependency on your NAR module to the
nifi-standard-services-api-nar NAR. This is handled by a custom
NarMojo for doing NiFi ARchive (NAR) packaging [1].
In the Gradle world we'll need a task to do the same thing, I believe
it is mostly a matter of getting the separate subprojects set up to
mimic the Maven modules, and a task (whether published as a plugin
like the NarMojo plugin is for Maven or not) to update the NAR
manifest and such. I have begun work on this [2], please feel free to
take a look and let me know what you think. At present I believe I am
missing a directive to copy all the processors' subproject
dependencies into the NAR output artifact, I think I know how to fix
it (i.e. from project(':processors').tasks['jar'].archivePath) but
haven't had time to try it out.
Please let me know if you'd like to work on the Gradle stuff together,
I would be happy to collaborate :)
Regards,
Matt
[1] https://github.com/apache/nifi-maven
[2] https://github.com/mattyb149/nifi-gradle-nar-example
On Tue, Jan 9, 2018 at 11:47 AM, Nicholas Deane <nd...@vitalimages.com> wrote:
> Hi,
>
> I’m working on a custom processor and want to utilize NiFi’s SSLContextService.
>
> In my build.gradle dependencies section, I’ve included:
> compile "org.apache.nifi:nifi-ssl-context-service-api:$nifiVersion"
>
> and in my code I’ve created the property descriptor with .identifiesControllerService(SSLContextService.class)
>
> When I’m configuring the processor, I noticed that the property on the processor says that it “Requires Controller Service: SSLContextService from my-custom-nar”. When I create a StandardSSLContextService from the default org.apache.nifi bundle, it doesn’t show up in the processor’s list (as expected based on that info message).
>
> I tried bringing in “nifi-ssl-context-service” and now I have two versions of StandardSSLContextService in the controller service list (one from the org.apache.nifi bundle and the other from my-custom-nar bundle). Is this how I should be doing something like this or is there a better way for me to use Controller Services across bundles and avoid having duplicates in that list?
>
>
> Notice - Confidential Information The information in this communication and any attachments is strictly confidential and intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, any dissemination, distribution, copying or other use of the information contained in this communication and/or any attachment is strictly prohibited. If you have received this communication in error, please first notify the sender immediately and then delete this communication from all data storage devices and destroy all hard copies.