It seems a very elaborate manual exercise:
- One has to check out each release tag of each component from required repository and try to build it (and format of release tag names may be inconsistent over the time).
- The build order will have to follow build-time dependency tree between components and versions (possibly switching revisions of the same repository multiple times).
To avoid discussion on how bad it is to re-build previously published artifacts, assume these artifacts were never published anywhere.
Is there any Maven support or other tools for this?
UPDATE:
To reduce the scale of the problem, instead of all versions, rebuild only necessary component versions to satisfy dependency tree of main component (root of dependency tree) at its current version, for example:
main-v2
├─A-v2
│ └─D-v1
│ └─E-v2
├─B-v1
└─C-v3
└─A-v1
└─E-v2
Note that A is required in two versions A-v1 and A-v2 - not just "the latest" while C is required in single version C-v3 even though there might be versions after that (C-v4, ...). In other words, diving into revision history is unavoidable even for single version of the root component.
Based on quick research, no well known tools support this.
Any links to solve the problem before reinventing the wheel?
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).