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
