Hi all: Here’s a few more data points…
Things were easy when we had no dependencies. Now that we’re using external libraries, we have to deal with the licensing and distribution of them, if we include them in the binary artifact. It’s not an issue with the source artifact, since the build includes scripting to download the dependencies from Maven Central at build-time. We don’t ship any dependency jar files with the source distribution, as per Apache policy. We publish all the actual produced jar files, along with their dependency metadata, to Maven Central. Downstream projects like ‘river-examples’, ‘Rio’, ‘Harvester’, ‘big-data’, etc, typically get the River jar files from there. The dependencies we have in trunk are on ‘asm’, ‘animal-sniffer’, ‘bouncy-castle’, ‘dnsjava’, ‘groovy’, ‘high-scale-lib’, ‘junit’, ‘hamcrest-core’, ‘mockito’, and ‘velocity’. Additionally, there’s a dependency the University of Illinois ‘imunit’ library that is currently commented out. Of those, only ‘velocity’ and ‘groovy’ are licensed under Apache Software License 2.0, although the others are compatible licenses. As it sits, the ‘release-bin’ target in trunk generates a binary artifact that does not comply with Apache’s license and notice requirements. To fix it so the artifact is compliant, we need to: - decide if we should ship the dependencies or just include documentation on what the user needs (the dependencies are documented in the Maven metadata). - It might sound simple to say “Just don’t ship the dependencies, then”, but the way the build script currently handles them is to copy them into the ‘lib’ folder rather than have a convoluted compile classpath. So “not shipping dependencies” would require either changing the way the classpaths are structured or specifically excluding the dependency jars”. Anyone who’s worked with Ant knows how much fun that is. - figure out which dependencies we should actually ship - some are needed for running an application, some are just to support the build, and aren’t needed by users. - assemble the correct NOTICE and LICENSE files for the binary release. This will depend on the decisions on what to ship. - Add scripting to ‘build.xml’ to build the ‘tar/zip’ artifact with the right notice and license files. Note that they _need_ to be different from the notice and license that are in the source distribution, if we ship dependencies with different licenses (Only Velocity and Groovy are ASL2). - Add some documentation on what jars are actually required to run the Jini platform, as opposed to the build tools. Probably a couple hours of work, but it’s a couple of hours that I’m not inclined to invest when I know it isn’t useful. How about if I comment out the lines that generate the current artifact, and whoever wants it badly enough can do the work to generate it properly? Cheers, Greg Trasuk > On Jan 21, 2016, at 10:31 AM, Patricia Shanahan <p...@acm.org> wrote: > > > > On 1/21/2016 3:24 AM, Simon IJskes - QCG wrote: >> On 21-01-16 09:51, Greg Trasuk wrote: >>> >>> In going through the exercise of cleaning up the release artifacts, >>> I’ve started to wonder if it actually makes sense to publish a >>> “binary distribution” of the JTSK separately from publishing the >>> artifacts to Maven Central. >> >>> Opinions? >> >> Please keep the binary distribution. I can't imagine that it is so hard >> to keep the few extra lines in the scripts. >> >> G. Simon >> > > As I understand it, the main argument for getting rid of the binary > distribution is a lack of practical uses. The most powerful counter to > that argument would be to describe one or more ways the binary > distribution is used, or is likely to be used in the future.
