Hi,
This is the first time I've heard of this requirement for user
applications. It certainly makes sense if the POM versions are incorrect. I guess one
question I have is why we don't make sure the POM versions are correct instead of
requiring a BOM? I think an application BOM is valuable anyway, so not arguing against
it, just wondering if we are putting duct tape on a broken window here.
Yep. Doesn't surprise me. We don't do communication here.
As far as I understand (and also from experience building IP), the root of
the problem is that:
A) there is a circular dependency between BOM and POM's
B) we only make "final" versions publically available
In more detail, each build that we run references a BOM to pull in the
correct versions of transitive dependencies. That version of the BOM is thus
added to the POM of the project that we're building. The BOM also references
all projects by version. So, to have complete consistency, each time any
project is re-built, all other projects and the BOM must also be rebuild.
In the normal maven world, this is handled because all the versions of the
project build are pushed out to some public repository, so it doesn't matter
if you pull in multiple versions of some dependency at build time.
Because having complete consistency is such a mammoth task [1], the plan
for future versions is to build incrementally, and then publish a BOM with
the correct versions for all artifacts at the end [2]. This leads to the
situation in B) above, where the transitive dependencies for any particular
artifact might not be available publically.
Unfortunately, we can't get it into current versions because the
SwitchYard application BOM doesn't exist. We can get it into future versions, but
that's something Kevin will need to work into the ERD for FSW 6.1 as this is really
only a problem with productized artifacts. We don't hit this in community.
It seems that we will have to do this for 6.1. Currently, we have the build
BOM's, and a suggested POM [3], but nothing more.
Thanks,
J
[1] It's a mammoth task because of the need to re-version every artifact
(currently a manual process) and rebuild. We have done this for components
of FSW/DV/BRMS/BPMS 6.0.0, and for the BOM's but the process doesn't really
scale.
[2] We plan to update our build BOM internally after each project build, but
not to make all the "interim" BOM versions available. The developer-facing
BOM's will be created for each public release (e.g. Alpha, Beta, GA) after
all the projects have been built.
[3] See:
http://dev138.mw.lab.eng.bos.redhat.com/candidate/soa-6.0.0-GA/fsw-6.0.0-...
--
Red Hat
Newcastle upon Tyne