kit based dependency management

For kit based dependency management,  I found that “importing dependencies” in maven will serve this purpose very well.   For example ,we have two kit cib-kit and rm-kit,

In cib-kit, we can specify the artifacts need to be exposed to other kit and their versions.

 

  <dependencyManagement>

     <!-- managed dependency -->

     <!-- only artifacts visible to external project /kit -->

      <dependencies>

        <dependency>

          <groupId>com.msci</groupId>

          <artifactId>cib-api</artifactId>

          <version>2.1-SNAPSHOT</version>

        </dependency>

      </dependencies>

  </dependencyManagement>

 

While on RM-side, in the rm-kit pom, we can import all exposed artifacts as dependencies from cib-kit

  <dependencyManagement>

     <!-- only artifacts visible to external project /kit -->

      <dependencies>

        <dependency>

          <groupId>com.msci</groupId>

          <artifactId>cib-kit</artifactId>

          <version>${cib.kit.version}</version>

          <type>pom</type>

          <!-- import all managed dependencies defined in cib kit pom-->

          <!-- in this case only cib-api will be imported -->

          <scope>import</scope>

        </dependency>

      </dependencies>

  </dependencyManagement>

  

In RM projects,  the imported dependencies are be directly used without specifying a version. The version will be resolved to the right one defined in cib-kit.

<dependencies>

    <dependency>

      <groupId>com.msci</groupId>

      <artifactId>cib-api</artifactId>

      <!-- no need to specify version here   version imported will be used -->

    </dependency>

   </dependencies>

 

Please refer to enclosed slides and sample project files for more details.

 

What to be exposed and  what versions are  are “controlled” by the kit providing dependencies,  and this will make the life of downstream kit much easier, and the same case for the build script.  Also for the whitelist, we can provide a BOM pom  as a kit which explicitly specify  all the dependencies.

 

For kit based release process, we can reuse most of current built script and to make it easy to adopted

 

For the first phase of the build tool,  we need to

a.       Update parent pom files (like RM-parent)  to turn them into “kits” by adding dependency management – specify what  artifacts inside the kid should be exported, and also what kids are to be imported.  For the versions, we can use SNAPSHOT or versioned SNAPSHOT for branching like 7.63-SNAPSHOT.

b.       Reuse current build script for kit build and release. we don’t need to update versions of a particular artifacts but to update the kit pom to ensure right kits are imported and right artifacts are exported.

c.       Provide maven plugins to allow this tool to be easily adopted for beginners.  These plugins will

a)       install python and related modules if they are not installed.

b)       Check out kit pom by specify a kit name (we should have a default location to store all kit information)

c)       Invoke build and release script.

d)       Invoke regression test script

d.       Integrate with jerkins or some build server – that should be direct forward since we can provide a maven command to jerkins.

下载方式:https://pan.quark.cn/s/a4b39357ea24 布线问题(分支限界算法)是计算机科学和电子工程领域中一个广为人知的议题,它主要探讨如何在印刷电路板上定位两个节点间最短的连接路径。 在这一议题中,电路板被构建为一个包含 n×m 个方格的矩阵,每个方格能够被界定为可通行或不可通行,其核心任务是定位从初始点到最终点的最短路径。 分支限界算法是处理布线问题的一种常用策略。 该算法与回溯法有相似之处,但存在差异,分支限界法仅需获取满足约束条件的一个最优路径,并按照广度优先或最小成本优先的原则来探索解空间树。 树 T 被构建为子集树或排列树,在探索过程中,每个节点仅被赋予一次成为扩展节点的机会,且会一次性生成其全部子节点。 针对布线问题的解决,队列式分支限界法可以被采用。 从起始位置 a 出发,将其设定为首个扩展节点,并将与该扩展节点相邻且可通行的方格加入至活跃节点队列中,将这些方格标记为 1,即从起始方格 a 到这些方格的距离为 1。 随后,从活跃节点队列中提取队首节点作为下一个扩展节点,并将与当前扩展节点相邻且未标记的方格标记为 2,随后将这些方格存入活跃节点队列。 这一过程将持续进行,直至算法探测到目标方格 b 或活跃节点队列为空。 在实现上述算法时,必须定义一个类 Position 来表征电路板上方格的位置,其成员 row 和 col 分别指示方格所在的行和列。 在方格位置上,布线能够沿右、下、左、上四个方向展开。 这四个方向的移动分别被记为 0、1、2、3。 下述表格中,offset[i].row 和 offset[i].col(i=0,1,2,3)分别提供了沿这四个方向前进 1 步相对于当前方格的相对位移。 在 Java 编程语言中,可以使用二维数组...
源码来自:https://pan.quark.cn/s/a4b39357ea24 在VC++开发过程中,对话框(CDialog)作为典型的用户界面组件,承担着与用户进行信息交互的重要角色。 在VS2008SP1的开发环境中,常常需要满足为对话框配置个性化背景图片的需求,以此来优化用户的操作体验。 本案例将系统性地阐述在CDialog框架下如何达成这一功能。 首先,需要在资源设计工具中构建一个新的对话框资源。 具体操作是在Visual Studio平台中,进入资源视图(Resource View)界面,定位到对话框(Dialog)分支,通过右键选择“插入对话框”(Insert Dialog)选项。 完成对话框内控件的布局设计后,对对话框资源进行保存。 随后,将着手进行背景图片的载入工作。 通常有两种主要的技术路径:1. **运用位图控件(CStatic)**:在对话框界面中嵌入一个CStatic控件,并将其属性设置为BST_OWNERDRAW,从而具备自主控制绘制过程的权限。 在对话框的类定义中,需要重写OnPaint()函数,负责调用图片资源并借助CDC对象将其渲染到对话框表面。 此外,必须合理处理WM_CTLCOLORSTATIC消息,确保背景图片的展示不会受到其他界面元素的干扰。 ```cppvoid CMyDialog::OnPaint(){ CPaintDC dc(this); // 生成设备上下文对象 CBitmap bitmap; bitmap.LoadBitmap(IDC_BITMAP_BACKGROUND); // 获取背景图片资源 CDC memDC; memDC.CreateCompatibleDC(&dc); CBitmap* pOldBitmap = m...
### Maven 中 `dependencyManagement` 的作用及使用方法 Maven 的 `dependencyManagement` 是用于集中管理项目中依赖版本的一种机制。它在多模块项目中尤为重要,能够统一依赖版本、减少版本冲突,并提升项目的可维护性和可扩展性。 #### 作用 1. **统一管理版本号**:通过在父模块中定义依赖的版本号,子模块在引用这些依赖时可以省略版本号,从而确保所有模块使用相同的版本。这有助于避免因不同模块使用不同版本而导致的兼容性问题[^2]。 2. **减少依赖冲突**:当多个模块引入相同依赖但版本不同时,`dependencyManagement` 可以有效避免版本冲突,确保依赖的一致性[^2]。 3. **简化依赖声明**:子模块在声明依赖时无需重复指定版本号,只需引用父模块中定义的依赖即可,从而简化了 `pom.xml` 文件的内容[^3]。 #### 使用方式 `dependencyManagement` 通常定义在父模块的 `pom.xml` 文件中,通过 `<dependencyManagement>` 标签包裹 `<dependencies>` 和 `<dependency>` 子标签来声明需要管理的依赖。 以下是一个典型的父模块中 `dependencyManagement` 的配置示例: ```xml <dependencyManagement> <dependencies> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.44</version> </dependency> </dependencies> </dependencyManagement> ``` 在子模块中,可以直接引用父模块中定义的依赖,而无需再次指定版本号: ```xml <dependencies> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> </dependency> </dependencies> ``` #### 与 BOM 结合使用 除了在父模块中直接定义依赖版本外,还可以通过 `BOM(Bill of Materials)` 来导入一组相关依赖的版本定义。BOM 是一种特殊的 POM 文件,用于统一管理一组相关依赖的版本,确保依赖间的兼容性。通过 `<scope>import</scope>` 导入 BOM,可以简化依赖版本管理,避免手动指定版本。 例如,使用 Spring Boot 的 BOM 来管理依赖版本: ```xml <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>2.7.14</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> ``` 在子模块中声明依赖时,可以直接使用 BOM 中定义的版本: ```xml <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> </dependencies> ``` 通过这种方式,可以确保所有依赖版本的一致性,并减少手动维护版本号的工作量。 ####
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值