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>

扫描二维码关注公众号,回复: 496441 查看本文章

      </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.

猜你喜欢

转载自dearls.iteye.com/blog/2185138
今日推荐