> I understand that convenience binaries might some issues with uberjars when we go that route for 1.0. But is there any issue with the uberjars as things currently stand? I was under the impression we are OK because we don't distribute them.
My impression is that this incorrect and it was the guidance of the mentors that we were indeed in a situation where we bundle dependencies as our build creates uberjars, thus we have to ensure that the jars contain the appropriate notices and license. This was done as part of METRON-531 (see https://github.com/apache/metron/pull/335 for the discussion between Josh Elsner and myself). It is my understanding that independent of whether we release binaries, the fact that our build system builds uber jars, we must ensure that the license and notices are correct within those bundled artifiacts of our build. Mentors, if I'm wrong in this, please let me know, but if I'm right, then it is likely that we need a change in process to keep these license and notices files updated in the individual projects *or* we could choose to stop creating uberjars. Casey On Wed, Sep 12, 2018 at 1:09 PM Michael Miklavcic < michael.miklav...@gmail.com> wrote: > I'm not sure I fully understand what is out of date. I know I have > personally modified our licenses a couple times in the past and used an > automated script that, I believe, Casey Stella had created for doing the > check. I even made some improvements to it a long ways back. It rips > through the maven dependency tree and tells you what isn't in the licenses > file and fails with a non-zero return code. I thought that was part of our > Travis build, or at the very least, the release lifecycle. Is that not the > case, or is there a different context we're talking about here? > > I understand that convenience binaries might some issues with uberjars when > we go that route for 1.0. But is there any issue with the uberjars as > things currently stand? I was under the impression we are OK because we > don't distribute them. It's part of the build, just like tools such as > JUnit, that we don't actually ship. > > Justin - These are the links for guidance that I've found. Is anything else > you've found that we should peruse while figuring this out? > > - https://www.apache.org/dev/licensing-howto.html > - http://www.apache.org/legal/release-policy.html#artifacts > > Mike > > > On Wed, Sep 12, 2018 at 10:29 AM Justin Leet <justinjl...@gmail.com> > wrote: > > > Hi all, > > > > As mentioned on the release voting thread, there was a Slack discussion > > around our LICENSE and NOTICE file likely being outdated because they > > haven't been actively kept up to date since graduation. I suggested on > the > > vote thread that we proceed with the current release, but consider it a > > blocker for the next release. > > > > Mentor input on this (and how other projects handle it), would be greatly > > appreciated. > > > > This discussion should result in JIRAs that are brought back to the > thread, > > so we can make sure to track this. > > > > For context, in addition to the standard L&N management, when we build > > artifacts we shade a lot of jars into a uberjars, thus bundling > > dependencies. However, our current releases are source only, but > > publishing convenience binaries came up in the 1.0 roadmap thread. > > > > I think there are a few things that need to happen to correct our current > > issue and make this easier in the future. > > 1) Get the LICENSE and NOTICE files up to date > > 2) Document the process we went through getting things up to date and > (just > > as importantly) the reasoning behind it. > > 3) Update the PR checklist to include LICENSE and NOTICE files for new > (and > > transitive) dependencies. > > 4) Update or add any processes we need to maintain this properly (e.g. > > release auditing) > > 5) Possibly build tooling for making some of this auditing easier (or use > > existing tool if anyone has suggestions)? > > > > Are there any other steps I'm missing that need to go into JIRAs? > > Any other concerns regarding these files that need to be addressed? > > Any other context I'm missing and that belongs in this discussion? > > >
