I ran my duplicate package detector utility on the lib/ directory of the CLI and the agent lib/ directory (as built in master) and got the following results. We need to look into possibly refactoring the code so the same package is not specified in two or more .jar files to avoid class loading issues when the jars are signed. $ java -cp ~/source/rhq/modules/test-utils/target/test-utils-4.3.0-SNAPSHOT.jar org.rhq.test.DuplicatePackagesDetector ~/source/rhq/modules/enterprise/remoting/cli/target/rhq-remoting-cli-4.3.0-SNAPSHOT/lib ====================================================================== org/rhq/core/server rhq-core-domain-4.3.0-SNAPSHOT.jar rhq-enterprise-server-4.3.0-SNAPSHOT-client.jar $ java -cp ~/source/rhq/modules/test-utils/target/test-utils-4.3.0-SNAPSHOT.jar org.rhq.test.DuplicatePackagesDetector ~/source/rhq/modules/enterprise/agent/target/rhq-agent/lib ====================================================================== org/rhq/core/clientapi/util rhq-core-client-api-4.3.0-SNAPSHOT.jar rhq-core-util-4.3.0-SNAPSHOT.jar
those duplicate packages (at least as seen in all the CLI jars) are still there: org/rhq/core/server rhq-core-domain-4.4.0-SNAPSHOT.jar rhq-enterprise-server-4.4.0-SNAPSHOT-client.jar which is potentially why bug #794503 is still happening.
master commits: b0bcb5d6f5ef3f3c28e00a2bee24e3e0599de525 - refactor domain jar's org.rhq.core.server package to org.rhq.core.domain.server 3266294b4768113f529df1d77b03e056579389e5 - generates classes in a unique package name (this was for bug #794503) bb92f0d2bf0ab28e71c775b8b3abef3adc5ff864 - moves the StringUtil from org.rhq.core.clientapi.util package (as found in core/util module) to org.rhq.core.util
QE: this needs to be verified in a JON Brew build ... (ie, not Jenkins)
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.