RTI Library class mismatch issues

[cliffcaseyyet]

This is a long explanation for a very very simple fix, but it might be worth understanding. This started as an attempt to get the createFederation to be idempotent in portico integration. In main right now you can see the exception if you try to get the federate to join a federation after it's already been created. In the process I finally figured out why all RTI exceptions were not firing appropriately.

Basically portico's impl would fire an exception (FederationExecutionAlreadyExists for instance) but the one on the classpath from the -cp {jar}:{lib} CLI loading would be the maven headers version, because -cp takes the first-declared version it encounters. This caused the valid (and handled) exception for a federation existing to throw an uncaught MethodNotFound because it did not like the exception from the headers maven package. Even if we handled this new exception it would not be very clean.

Next thing I tried was loading lib first, i.e. -cp {lib}:{app} and yes this actually works but then the "running" app is actually the lib and the logs don't show the app. That can also be mitigated with an extra CLI arg for log4j pointing to app's log config, but it was becoming more complex than it should be to launch and I suspect there were other effect to having lib be the primary declared application.

Then I realized (and confirmed with testing on both RTIs) there is no reason whatsoever to include the headers in the finished jar.

TL;DR: Headers get yeeted before package now and everything works better.