[ https://issues.jboss.org/browse/DROOLS-471?page=com.atlassian.jira.plugin... ] Geoffrey De Smet edited comment on DROOLS-471 at 5/2/14 9:32 AM: ----------------------------------------------------------------- Check the assembly xml's, they often reference dependencies for excludes because the target app server already contains that jar. Note: those assembly xml's are the recipe to build the wars/zips. Until we have arquillian tests that test the wars on all targeted app servers, there's always a chance that any dependency change breaks something. That doesn't mean we should stop improving our dependencies and or build :) It just means there's a known risk and we should do a best effort when changing them: - Every time you remove a dependency, it's recommended to look for it's groupId in all files, especially in all pom.xml and all assembly-.xml files. But if an issue does slip through, don't blame the guy trying to improve our deps, blame the lack of arq tests. was (Author: ge0ffrey): Check the assembly xml's, they often reference dependencies for excludes because the target app server already contains that jar. Note: those assembly xml's are the recipe to build the wars/zips. Until we have arquillian tests that test the wars on all targeted app servers, there's always a chance that any dependency change breaks something. That doesn't mean we should stop improving our dependencies and or build :) It just means there's a known risk and we should do a best effort when changing them: - Every time you remove a dependency, it's recommended to look for it's groupId in all files, especially in all pom.xml and all assembly-.xml files. But if an issue does slip through, don't blame the guy trying to improve our deps, blame the lack of arq tests. -- This message was sent by Atlassian JIRA (v6.2.3#6260)