METRON-2311: Remove JUnit from all our uber jars

[justinleet]

Contributor Comments

Couple things

• added JUnit exclusions into all the uber jars. For dependencies on hbase-shaded-client these exclusions are on a class level, rather than a dependency level. I believe this is because of the shaded jar's construction, but I'm open to suggestions
  • JUnit 4 and 5 are included, so I'm not redoing half the work in METRON-2307: Migrate to JUnit5 #1554 and because it doesn't hurt anything
• Added exclusions on json-simple, which pulls JUnit in as default (compile) scope.
• dependencies_with_url.csv updated to drop JUnit.
• Updated StellarProcessorUtils.java to remove JUnit from src in favor of throwing AssertionError. I'm not convinced that a subclass of Error is the appropriate thing to do, but it's the underlying JUnit does, so I basically just moved that semantic into our code for this purpose.

Pull Request Checklist

Thank you for submitting a contribution to Apache Metron.
Please refer to our Development Guidelines for the complete guide to follow for contributions.
Please refer also to our Build Verification Guidelines for complete smoke testing guides.

In order to streamline the review of the contribution we ask you follow these guidelines and ask you to double check the following:

For all changes:

• Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
• Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
• Has your PR been rebased against the latest commit within the target branch (typically master)?

For code changes:

• Have you included steps to reproduce the behavior or problem that is being changed or addressed?

• Have you included steps or a guide to how the change may be verified and tested manually?

• Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:

  mvn -q clean integration-test install && dev-utilities/build-utils/verify_licenses.sh 
  

• Have you written or updated unit tests and or integration tests to verify your changes?

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?

• Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?

For documentation related changes:

• Have you ensured that format looks appropriate for the output in which it is rendered by building and verifying the site-book? If not then run the following commands and the verify changes via site-book/target/site/index.html:

  cd site-book
  mvn site
  

• Have you ensured that any documentation diagrams have been updated, along with their source files, using draw.io? See Metron Development Guidelines for instructions.

Note:

Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.
It is also recommended that travis-ci is set up for your personal repository such that your branches are built there before submitting a pull request.

[justinleet]

After a maven install of the project,

find ./ -name "*uber*jar" | xargs -I{} jar tf {}  | grep junit

shouldn't return any results.

[mmiklavc]

How again are we getting test deps in the uber jars in the first place?

[justinleet]

• json-simple pulls it in as compile scope
• hbase-shaded-client seems to just pull JUnit along for the ride.
• stellar-common carried it along because of the JUnit in src, so even though it was excluded from the uber jar, anything that pulled it in as a dep was still pulling in compile level JUnit.'

We probably could be less aggressive about killing it from the uber jars, but playing whack-a-mole was kind of a pain.

[mmiklavc]

+1