river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Does it really make sense to have a "Convenience Binary" artifact?
Date Thu, 21 Jan 2016 16:28:52 GMT
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 <pats@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.


Mime
View raw message