Github user kevdoran commented on a diff in the pull request:
https://github.com/apache/nifi-minifi/pull/118#discussion_r176297389
--- Diff:
minifi-c2/minifi-c2-commons/src/main/java/org/apache/nifi/minifi/c2/model/extension/ExtensionComponent.java
---
@@ -0,0 +1,85 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ * http://www.apache.org/licenses/LICENSE-2.0
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.minifi.c2.model.extension;
+
+import io.swagger.annotations.ApiModel;
+import io.swagger.annotations.ApiModelProperty;
+
+import java.util.List;
+import java.util.Set;
+
+/**
+ * A component provided by an extension bundle
+ */
+@ApiModel
+public class ExtensionComponent extends DefinedType {
+
+ // TODO, does arch/binary/compiler metadata need to be added here?
--- End diff --
Ok, so here is what I came up with for now:
An extension component is uniquely identified by (bundle, type), where
bundle = (group, artifact, version) and type is a fully qualified class name.
Bundle is optional in the case that you have an extension component outside of
a bundle (common in the C++ case for now), in which case the fully qualified
type must be globally unique.
An extension component implementation is uniquely identified (bundle, type,
build) where build = (version, revision, timestamp, target architecture,
compiler, compiler flags)
In general, a flow designer should only have to target an extension
component in order to author a flow. Whether or not a flow can run on a given
agent depends on if the extension component has an available implementation on
that agent.
It's still a bit hand-wavy (at least for now), but I think this distinction
should work once we have more dynamic authoring and deployment logic that
leverages a fully featured device registry and extension registry. For now, we
will focus on agent class name compatibility, so we will have to assume that
manifests for classes don't change (or at least, don't remove capabilities) and
use the intersection of all agent manifest capabilities when designing against
a an agent class label.
I need to flesh it out a bit more, but I think it should work. To get a
sense of what some of this looks like in code, look at the equals/hashcode
methods for DefinedType and ExtensionComponent after I push my next commit.
---
