[ https://issues.apache.org/jira/browse/NIFIREG-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16688251#comment-16688251 ]
Bryan Bende edited comment on NIFIREG-211 at 11/15/18 3:50 PM: --------------------------------------------------------------- I think so... I was thinking that there would be a way to create a bundle entity in the registry with a link to the external content, not sure on the terminology yet, but kind of like "managed vs unmanaged" or "internal vs external". The main use case I was thinking of was when we do apache releases, all of the NARs are already in Maven central, so it might be nice if someone could stand up a registry instance somehow pointing at those NARs. The challenge though is that in order to create that entity, the client would need to supply all of the metadata that is normally extracted directly from the bundle. For example, if someone uploads a NAR we are going to extract all the info from the manifest like group/artifact/version, the dependency group/artifact/version, and a new component descriptor that is going to be added with all the metadata about the components in the bundle... so without having the actual NAR, then we need a way to obtain all of this information. was (Author: bende): I think so... I was thinking that there would be a way to create a bundle entity in the registry with a link to the external content, not sure on the terminology yet, but kind of like "managed vs unmanaged" or "internal vs external". The main use cause I was thinking of was when we do apache releases, all of the NARs are already in Maven central, so it might be nice if someone could stand up a registry instance somehow pointing at those NARs. The challenge though is that in order to create that entity, the client would need to supply all of the metadata that is normally extracted directly from the bundle. For example, if someone uploads a NAR we are going to extract all the info from the manifest like group/artifact/version, the dependency group/artifact/version, and a new component descriptor that is going to be added with all the metadata about the components in the bundle... so without having the actual NAR, then we need a way to obtain all of this information. > Add extension bundles as a type of versioned item > ------------------------------------------------- > > Key: NIFIREG-211 > URL: https://issues.apache.org/jira/browse/NIFIREG-211 > Project: NiFi Registry > Issue Type: Improvement > Reporter: Bryan Bende > Assignee: Bryan Bende > Priority: Major > Fix For: 0.4.0 > > > This ticket is to capture the work for adding extension bundles to NiFi > Registry. > This work may require several follow on tickets, but at a high-level will > include some of the following: > - Add a new type of item called an extension bundle, where each bundle > can contain one ore extensions or APIs > > - Support bundles for traditional NiFi (aka NARs) and also bundles for > MiNiFi CPP > > - Ability to upload the binary artifact for a bundle and extract the > metadata about the bundle, and metadata about the extensions contained > in the bundle (more on this later) > > - Provide a pluggable storage provider for saving the content of each > extension bundle so that we can have different implementations like > local fileysystem, S3, and other object stores > > - Provide a REST API for listing and retrieving available bundles, > integrate this into the registry Java client and NiFi CLI > - Security considerations such as checksums and cryptographic signatures for > bundles -- This message was sent by Atlassian JIRA (v7.6.3#76005)