Yes please keep animal sniffer, it is used for api compatibility testing. dns-java is used in the test libraries, but considering it cannot be used in Java 9, we might as well remove it.
The reggie-test-service-provider depends on sun's implementation of java 6,7 and 8. It cannot be used in 9, or in IBM's j9 or any other jvm. It is used by tests that are only run on the platforms that it supports. Java 9 provides a list based alternative that can be used for tests. I'd take a pragmatic approach to this, there us no use for it outside testing, we can include the license inside the jar, if we want to be compliant with apache policy. This is a case of doer decide, if you want to delete it along with the test, I won't argue against it. The license for Cliff Click's high scale lib is Creative commons public domain. Not sure about the boundary fork, I haven't tested it. This is an optional dependency it is used by CombinerSecurityManager to provide a checked Permissions cache because it is non blocking and memory efficient. Non blocking prevents deadlock in circular execution paths. CombinerSecurityManager prevents repeated security checks for identical AccessControlContext's. Can't see any problems with using a later version of groovy as it is not a compiled language. Has any syntax in the earlier version been removed from the latter? Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Greg Trasuk <tras...@trasuk.com> Sent: 16/01/2016 05:20:48 pm To: d...@riverapache.org Subject: Usage of libraries in dep-libs in trunk So, we know we can’t ship jar files in the source distribution - I’m looking at replacing dep-libs with an ivy script that downloads the dependencies at build time, and I have a few questions… - Are we actually using animal-sniffer for anything? There’s an ant task in hudson.xml that checks signatures, but I wonder if we’re actually using it. It’s not clear to me how to get the signatures from Maven Central, and before I look further I’d like to know what we’re doing with them. - Same as above for ‘dnsjava’. It gets copied into ‘lib-ext’ but I can’t find anywhere that ‘lib-ext’ is actually used. - I’m not sure what to do with ‘reggie-test-nameservice-provider’. The implementation classes used to be in the qa/src folder, but they’ve been moved out to a Maven project that is included as the jar and source-jar under dep-libs. The Foundation doesn’t encourage leaving jar files in the source distribution, so it would seem like we shouldn’t leave it as-is. Options would be to release it separately, so we could pick it up out of Maven Central, or put the actual Maven project into trunk, or to put the classes back into qa/src and build them the old way. Opinions? - high-scale-lib is available from Maven Central as com.boundary:high-scale-lib:1.0.6 (that’s what’s called out in the pom file for jsk-platform.jar) but I can’t find any indication of what the license is. There’s no license in the source jar that’s on Maven Central. As such, I’m not sure if we can use it. Anybody know? There are other versions of high-scale-lib in Maven Central that have a public domain notice, but (a) I don’t know if a public domain license can be bundled with an Apache project, and (b) We’d have to test with the other library. I think that would fall to Peter, as he knows best what ‘trunk’ is using the library for. - deps-lib calls out groovy 2.3.8, but the latest rev is 2.4.5 in Maven Central. Will there be a problem with using the latest version? How do we test this? Cheers, Greg Trasuk