开发者

Is recursive publishing possible / easy in Gradle?

开发者 https://www.devze.com 2023-03-16 11:03 出处:网络
We have an Ant and Ivy-based build management system, which basically consists of a shared ant file and a set of conventions around directory structure.

We have an Ant and Ivy-based build management system, which basically consists of a shared ant file and a set of conventions around directory structure.

One hurdle I'm trying to overcome i开发者_StackOverflow中文版s the fairly common case of "recursive publish". Say, we have 5 in-house code modules that have a dependency graph like this:

Is recursive publishing possible / easy in Gradle?

  • Each module should publish its ivy artifacts to our internal repo
  • Artifacts not yet cleared for deployment to test should have status "integration"
  • Artifacts deployable to test should have status "milestone" (manually promoted by developer)
  • Artifacts verified by testers should have status "release"

Say a developer has all 5 modules checked out locally, and has made changes to them all. Now he wants to promote all his changes to "milestone" status. In other words what should happen in the ivy repo is:

  • e-1.0-RC1 gets published
  • d-1.1-RC2 gets published, referencing e-1.0-RC1 as a dependency
  • c-2.0-RC1 gets published, referencing d-1.1-RC2 as a dependency
  • b-3.3-RC1 gets published, referencing e-1.0-RC1 as a dependency
  • Finally, a-7.1-RC2 gets published, referencing c-2.0-RC1 and b-3.3-RC1 as dependencies.

I haven't found an easy way to do this using ivy + ant (Ivy promises something similar called recursive deliver, but I can't find any working examples of it).

Gradle sounds promising here since it seems to have good support for multi project builds. I did skim through the docs, but didn't immediately find this case as an example. Is there an easy way to achieve this with gradle?


The only way I can conceive of this working is with a master build file that propagates version numbers down to the individual build files for each of your modules. This has the unfortunate side effect of binding your five modules into a unit that would need to be managed as a single entity but it may be the only way to achieve what you're looking for.


That looks like a normal multi-project build to me. Assuming you are doing a JVM-based language, Gradle has good out-of-the-box support using conventions (you are free to override those conventions to match your projects' needs) - try it and see.

Feel free to ask for more specific detail on a multi-project build using Gradle.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号