Re: Does it really make sense to have a "Convenience Binary" artifact?
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 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.
Re: Does it really make sense to have a "Convenience Binary" artifact?
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.
Re: Does it really make sense to have a "Convenience Binary" artifact?
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 -- QCG, Software development, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Does it really make sense to have a "Convenience Binary" artifact?
I think that's fair enough, let's makes things as simple and easy as we can. Building from source isn't that hard, especially given all the effort you and others have put into the build scripts. If new users want something easier to get started with you've listed several options that they have. Cheers, Tom On Thu, Jan 21, 2016 at 8:51 AM, 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. > > Basically, there is nothing in the JTSK that you can "just run”. Contrast > this with something like Tomcat, where you might download the binary > distribution and “just run” the web server. All you can do with the JTSK > as it stands is run the QA suites. To do that essentially requires > starting from the source distribution, since the Ant scripts do a build > before running the integration testing (and it really isn’t practical to > run the tests without the Ant scripts). The browser jar is there, but > frankly should probably be taken out (as we did in the 2.2 branch), because > to actually use it you need binaries, policy files, etc, which haven’t been > maintained in the JTSK for years. People should start from the > river-examples project, or Rio, or Harvester or StartNow if they want to > setup a Jini infrastructure and play with it. > > Any useful examples or applications will be getting the compiled jars from > Maven Central (via Maven, Gradle, or Ivy). I suppose one might argue that > it’s useful to ship the collection of compiled jars with their dependencies > (Groovy and high-scale-lib), but I suspect that most people are using > dependency management theses days. So I’m not sure if it’s worth the > effort to maintain the packaging scripts and the alternate license and > notice files that we would need for a binary release. > > Opinions? > > Cheers, > > Greg Trasuk
Does it really make sense to have a "Convenience Binary" artifact?
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. Basically, there is nothing in the JTSK that you can "just run”. Contrast this with something like Tomcat, where you might download the binary distribution and “just run” the web server. All you can do with the JTSK as it stands is run the QA suites. To do that essentially requires starting from the source distribution, since the Ant scripts do a build before running the integration testing (and it really isn’t practical to run the tests without the Ant scripts). The browser jar is there, but frankly should probably be taken out (as we did in the 2.2 branch), because to actually use it you need binaries, policy files, etc, which haven’t been maintained in the JTSK for years. People should start from the river-examples project, or Rio, or Harvester or StartNow if they want to setup a Jini infrastructure and play with it. Any useful examples or applications will be getting the compiled jars from Maven Central (via Maven, Gradle, or Ivy). I suppose one might argue that it’s useful to ship the collection of compiled jars with their dependencies (Groovy and high-scale-lib), but I suspect that most people are using dependency management theses days. So I’m not sure if it’s worth the effort to maintain the packaging scripts and the alternate license and notice files that we would need for a binary release. Opinions? Cheers, Greg Trasuk
