Bug 1006607

Summary:	jboss-integration platform BOM: Minimize exclusions to only those that fix (unanimously agreed) bugs in the dependency's pom
Product:	[Retired] JBoss BRMS Platform 6	Reporter:	Nick Cross <ncross>
Component:	Build and Assembly	Assignee:	Geoffrey De Smet <gdesmet>
Status:	CLOSED NOTABUG	QA Contact:	Lukáš Petrovický <lpetrovi>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	6.0.0	CC:	etirelli, gdesmet, rzhang
Target Milestone:	ER5
Target Release:	6.0.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-12-04 09:18:54 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1017745, 1019906

Description Nick Cross 2013-09-10 21:47:42 UTC

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.

Comment 2 Geoffrey De Smet 2013-09-11 09:35:23 UTC

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.

Comment 5 Geoffrey De Smet 2013-10-14 10:49:26 UTC

@Edson sure

Comment 6 Geoffrey De Smet 2013-10-14 10:59:07 UTC

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

Comment 7 Ryan Zhang 2013-12-04 09:18:54 UTC

Nick and I both think we already have agreement on the process how to handle this case.

Close this issue now.