Currently the community integration bom has dependencies in the dependencyManagment that include exclusions. The recommendation from EAP is not to have exclusions in a BOM.
Problem by not doing the exclusions is that we have to overwrite the dependencies in order to do them. That's a DRY violation. There are 2 types of exclusions: 1) Exclusions to avoid duplicate dependencies in the classpath. For example because of an artifact that changed its groupId. For example: A depends on "org.javassist:javassist" and B depends on "javassist:javassist". The common solution is to exclude the "javassist:javassist" problem. 2) Exclusions for plain bugs in the pom metadata. For example an unneeded non-test scope dependency on junit, cobertura or mockito. Or for example, a non-test scope dependency on slf4j-log4j12 (because reusable jars should not force the logging implementation, they should only depend on slf4j-api). Not sure how we want to resolve this, but we 'll need to make a decision. Note: SY and KIE haven't agreed on the exclusions yet.
@Edson sure
Conclusion after discussion with Horia (Modeshape): 1) Exclusions in a bom or parent pom, cannot be overwritten by child poms (they can only be manually re-added which is a big pain). Therefore, if anyone (*) disagrees on any exclusion, it's removed. So we need to be unanimous (silence == agreeing). 2) Some dependency's poms have outright bugs. Exclusions to fix these bugs make perfect sense. Therefore, we keep those exclusions. But again, if anyone (*) disagrees that it's not a bug (that the exclusion is invalid in some cases) the exclusion is removed. (*) anyone from projects that actually use that dependency
Nick and I both think we already have agreement on the process how to handle this case. Close this issue now.