Hi,
The reason I linked 6.1.0-redhat-1 is because that's the version
directly referenced by resteasy-jaxrs-all here:
http://maven.repository.redhat.com/techpreview/all/org/jboss/resteasy/res...
Keep in mind, I'm not arguing against the value of an application BOM. I'm just
trying to provide some context around where we stand w/r/t a SwitchYard / FSW BOM today.
To summarize:
There is no SwitchYard or FSW application BOM today. There is the integration platform
BOM, which would have to be imported into any application BOM anyway, so users can always
import that via depenencyManagement for now.
Right. We can't fix the bug report in any other way with the currently
released artifacts. It is a build problem, but it's because the platform
POM's can reference builds that aren't publically available.
Adding an application BOM for SY is a good thing to do. If we must
have this for FSW 6.1, then it needs to be in the PRD/ERD so that we can reflect it in the
product scheduling.
From this discussion, some BOM is required. Whether we continue to
use the
build BOM or provide application BOM's for 6.1 is up for discussion, but
it
makes sense to provide the latter. Note, that we'd already assumed that
we'd have to, but we'll still need a template of the list of artifacts, and
we can add the correct versions to that.
I'm not sure about anyone else, but I was never told that a BOM
was required in order to work around a broken dependency chain in our enterprise Maven
repository.
We (productisation) knew that it was required for us to build. However, the
process of getting something that developers use, especially in the case of
the tooling, was unclear to me (hence my original mail).
Thanks,
J
PS. Adding all the internal builds to our maven repository would be one
way to fix this, but then my mailbox will fill up with complaints that the
maven repository is too large (yes, this does already happen).
--
Red Hat
Newcastle upon Tyne