Its easy to do what Andy is describing using maven's assembly plugin in the maven world. I have no experience with sbt so can't speak to how it can be done with Sbt and would defer that to the experts.
We hit a similar issue with licenses in source and binary on the first Pirk release last week. We finally decided to make a source-only first release while we r now working on fixing the binary license packaging for the next release. On Mon, Sep 5, 2016 at 2:05 PM, Andrew Purtell <andrew.purt...@gmail.com> wrote: > It covers LICENSE and NOTICE file generation for both source and binary > releases, and inclusion of the resulting files in source archives, binary > jars, and binary archives through integration with the maven build and > assembly targets. > > Including the complete text of any given license in LICENSE is important > but only needs to be done once. You retain the copyright notice and mention > of the license type per dependency. We are just talking about > deduplicating, eg 100 full texts of the ASLv2 into one. > > > On Sep 5, 2016, at 10:45 AM, Pat Ferrel <p...@occamsmachete.com> wrote: > > > > Thanks Andy. > > > > RE “Only need to include one entry with the complete text of a license, > everything else can just name the license.” So the copyright notice in the > license is not important, only the license type? This is often the only > important difference in the license from one dep to another. > > > > It sounds like your automation covered LICENSE.txt creation? or just > inclusion in the binary? > > > > > > On Sep 5, 2016, at 9:59 AM, Andrew Purtell <andrew.purt...@gmail.com> > wrote: > > > > I won't weigh in on the question at hand but I'd like to make a couple > of clarifications for what it is worth: > > > >> This yielded 166 deps, so this implies we need to include 166 licenses > and copyright notices in LICENSE.txt. > > > > There are some available simplifications: > > > > - Only need to include one entry with the complete text of a license, > everything else can just name the license. > > > > - Where there are multiple artifacts coming from a single project, like > Hadoop, only one entry for the project is needed. > > > >> Donald is looking at automating this but I’m personally dubious > > > > As I think I've mentioned before here we have successfully automated > this for HBase (based on automation done by yet other Apache projects) so I > hope you'll take my advice and evidence based assertion it can be done. > Caveat: we use maven not SBT as build framework. > > > > > >> > >> On Sep 5, 2016, at 9:43 AM, Pat Ferrel <p...@actionml.com> wrote: > >> > >> This weekend I tracked down all out deps, which required a few scripts > to process sbt output. This yielded 166 deps, so this implies we need to > include 166 licenses and copyright notices in LICENSE.txt. As I read the > Apache guidelines this should be the license that goes with the version we > include since the copyright owner of license may have changed in newer > versions. > >> > >> This may be near impossible to maintain by hand if we have frequent > dependency upgrades and frequent releases. Donald is looking at automating > this but I’m personally dubious about this because it require all 166 deps > have maintained their licenses in artifacts for all versions we might use. > >> > >> A source release requires that *only* the source included be reflected > in LICENSES.txt. This would be ~0, I think a couple things are included. > >> > >> Several things lead me to favor a source-only release: > >> 1) 166 licenses needed for binary ~0 needed for source—I’d rather we > spend time on things that add more value > >> 2) I have never used the binary release. Any version of a source > download and `./make-dirstribution` works universally. > >> 3) our install.sh now installs source and builds it for the user. This > is good because we can use the same script for unreleased -SNAPSHOT > versions sitting in the `develop` branch. > >> 4) outside of instructions for downloading and installing the binary > that do not yet exist afaik, there would be no obvious way for the user to > get the binary. > >> 5) indirectly any delay to release is getting to be a serious problem. > We haven’t had a well supported release from the main project since close > on a year ago and work on new features is being delayed. > >> 6) we can do a source only release now and be clean of the license > issue as far as the IPMC is concerned. We can add binary when we have a > better answer to automation. In other words why hold the release for binary? > >> > >> Since this decision will affect the project for as long as it is in > incubation. I’d like to see what others think. I believe we can release now > if we do source-only. > >> > >> Source only, or source & binary? > > >
