[
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)
