Weaver is dependent on jax-rs instrumentation module classes being read from the module jar in a specific order

[jasonjkeller]

The weaver loads & caches each instrumentation module in CachedWeavePackage.load by locating the instrumentation module jar and reading in the bytes for the all of the classes contained in the module.

It appears that the weaver depends on the classes being read in from the JarInputStream from the jar (newrelic.jar!/instrumentation/jax-rs-1.0-1.0.jar) in a specific and predictable order for the jax-rs-1.0 instrumentation.

Specifically, the JavaxWsRsApi_Instrumentation class needs to be read in before JavaxWsRsApi_Subresource_Instrumentation or the instrumentation will fail to apply with a WeaveViolation (see CLASS_MISSING_REQUIRED_ANNOTATIONS) in cases where jax-rs sub-resources are being used and do not include the @Path annotation.

The reason is that a map of all method annotations is updated in WeavePackage.processWeaveBytes when each of the classes mentioned above are processed. In the map (Map<String, ClassNode>) annotations are mapped to a weaveNode (either JavaxWsRsApi_Instrumentation or JavaxWsRsApi_Subresource_Instrumentation).

As it currently works JavaxWsRsApi_Subresource_Instrumentation needs to be processed last so that it replaces the weaveNode values in the map for the sub-resource instrumentation to work properly.

As it stands, this approach is brittle and subject to breaking because there is no guarantee that the classes will be added and read from the jax-rs-1.0-1.0.jar in a deterministic manner given that the build process can vary depending on the environment that it is run in.

[jasonjkeller]

This PR forces gradle to build the instrumentation jars in a deterministic manner that fixes the issue.
#232

However it would be ideal if the weaver didn't depend on such things.