In a project I worked on, we had a similar structure. Translated to Camel
artifacts, it would result in the following:
- camel pom: Defines generic properties, deployment profiles, plugin
management, etc
- new camel-oss pom i.e. oss BoM: has top-level 'camel' artifact as parent,
defines properties
Hi,
Why don't you do it the other way around?
I understand from Claus that his desire is not so much to manage the
dependencies and their versions in a different file, but just to provide a
file where the version properties can be easily read from and diffed
between releases.
In that case, you c
