业务背景
算子与算子的代码之间可能有一些公共的数据模型，常量，算法等，这些公告代码需要和算子一起加到算子包中，打包一块发布
实现方案讨论
AI的思路非常清晰，我也觉得使用公共库的方式更合适，接下来继续细化
AI直接输出方案初稿了，我们让他再优化一下
原始诉求
现在我们已经在用着一个算子包，为了保证能兼容，我希望现在这套算子管理系统在打包输出时能兼容支持，之前可能设计的不是太好，我想着为保证通用性，是不是让算子管理系统可以给推荐的打包路径格式，但也允许用户自定义每一个库或算子的打包路径
现有的算子包结构：
{根目录}/
- models/. #到时会做成一个模型库
- a.groovy
- b.groovy
- operators
- constants/. #到时会做成一个常量库
- const1.groovy
- const2.groovy
- groovy/. #算子代码存放位置
- operator1.groovy
- operator2.groovy
- method/. #到时做成公共方法库
- commonmethod1.groovy
- commonmethod1.groovy
- metainfo_operators.yml. #存放算子元数据
metainfo_operators.yml元数据示例
businessName: aname
version: 1.0
operators:
instances:
- operator_code: an_operator_code
name: operator name
object_code: object_code_of_the_operator
data_format: data format of the operator
generator: Generator of the operator
order_no: 算子在算子包中的执行顺序，一个数字
沟通优化
方案设计文档
算子包打包路径配置与公共库管理 - 需求设计