从封闭源重建所有Maven组件的所有版本(没有工件存储库)

时间:2015-06-22 13:38:37

标签: java maven nexus

这似乎是一个非常精细的手动练习:

  • 必须从所需的存储库中检出每个组件的每个发布标记并尝试构建它(并且发布标记名称的格式可能会随着时间的推移而不一致)。
  • 构建顺序必须遵循组件和版本之间的构建时依赖关系树(可能多次切换同一存储库的修订版)。

为避免讨论重建以前发布的工件有多糟糕,假设这些工件从未在任何地方发布过。

是否有Maven支持或其他工具?

更新

要减少问题的规模,而不是所有版本,只重建必要的组件版本,以满足main组件(依赖关系树的根)的依赖关系树当前版本,例如:

main-v2                                                                 
├─A-v2
│ └─D-v1
│   └─E-v2
├─B-v1
└─C-v3
  └─A-v1
    └─E-v2

请注意,AA-v1这两个版本需要A-v2 - 而不仅仅是"最新的"}尽管在此版本C之后可能存在版本C-v3,但在单个版本C-v4中需要.withAudioCodec('libmp3lame') .toFormat('mp3') .outputOptions('-id3v2_version', '4') .outputOptions('-metadata', 'title=' + songTitle) .outputOptions('-metadata', 'artist=' + songArtist) 。换句话说,即使对于单个版本的根组件,潜入修订历史也是不可避免的

基于快速研究,没有众所周知的工具支持这一点。

在重新发明轮子之前解决问题的所有链接?

1 个答案:

答案 0 :(得分:2)

As far as I know there is no tooling in Maven or other tools for this sort of approach. I would also suggest NOT to go down that road but rather try to figure out what the actual problem is you are trying to prevent and work out a less laborious and less complex solution. If you have no choice the best I can think of is to setup a build for each project source on a CI server and then change branch and kick off one build after another. If you use a parameterized build for it you can even automate that with an external script that invokes the different builds. It will still be potentially a LOT of work but at least that way you keep the logs all in one place and can repeat things if they fail and so on. Of course if build systems change on the fly between branches/releases and so on you will have to adapt things. You could also create a new build config for each release by starting off with one and then just copying the working plan and changing it's SCM details. And of course this also allows you to hook it up for notifications e.g. via email and so on. Also in your added clarification you might not need to build a-v1 since the dependency to it would be removed since the A-v2 is higher in the dependency tree. In either case though... I would break it up into CI builds and build the components per release and publish them to Nexus until you can build the component you actually need (main).