Actually, this does not imply circular workflow, just a painful one :)
1) I want to release a new version of inventory and decide what its version
is
gonna be.
2) I update parent POM with the new inventory version and release the parent
POM. Note that at this point in time no one is using this version of parent
and that inventory hasn't been released yet.
3) I update inventory with the new parent POM version and release it with the
intended version.
So to break the circle outlined by Peter, you have to basically introduce a
race condition and also double the number of releases we do.
Note that the above workflow would work with a BOM, too.
Out of curiosity, then how other projects works ? Can we adopt some best practice to
reduce our complexity ?
There are projects using bom and parent, and they have versions on both.
If at the end of the story, there is a manual step of synchronization (i.e. I have to go
to a place a look which version I need), I would like to see if we can get benefit in
someway without adding circular dependencies or painful process.
With the srcdeps plugin, we added an additional feature that helped in a sense.
Is there a possibility to sync some property versions without entering on the circular
dependency ?
I am brainstorming, but what about a repo where we put these versions, and we can have
just a plugin to warn if we are using correct ones ? (without having to place it on
parent).
I.e. In alerts I'm using a parent X and bus Y, and this plugin can check from the repo
that my versions are not updated.
So, manual step is not avoid but we are warned that for alpha8 target versions are a,b,c.
When I release a new alerts, I can update that in the repo.
Thoughts ?