On Mon, Nov 28, 2016 at 12:00 PM, Greg Trasuk <[email protected]> wrote: > ... > >>> You may or may not have come across “Apache RAT”, or the Release Auditing >>> Tool. This is part of the Apache Creadur project, and is a very useful >>> tool to check licensing status of files. When I run RAT agains >>> guacamole-client, we can see that the archive is full of compiled classes >>> and a few jar files. That’s going to be a problem for releasing the >>> artifact. >>> >> >> The RAT plugin is actually already part of the guacamole-client build, >> which will fail unless it passes RAT. >> >> When you say you are running RAT against guacamole-client, are you >> running it against guacamole-client after having already run "mvn >> package" (or similar), and thus RAT is choking on build artifacts and >> their dependencies? There are no compiled classes nor .jar files >> within the guacamole-client artifact itself. >> > > When I run ‘mvn clean install’ or ‘mvn clean package’, I get a rat failure: > > 1 Unknown Licenses > > ***************************************************** > > Files with unapproved licenses: > > > /Users/trasukg/devel/guacamole/guacamole-client-0.9.10-incubating/guacamole/src/main/webapp/generated/templates-main/templates.js > > I agree that appears to be a false positive (as it’s a generated file) - > maybe we’re missing an exclusion? >
Yes. This isn't happening for a copy cloned from git, but it does happen with the .tar.gz. Apparently RAT parses the .gitignore by default and uses those exclusions, but the .gitignore is absent from the .tar.gz, thus the build is inconsistent. http://creadur.apache.org/rat/apache-rat-plugin/check-mojo.html#parseSCMIgnoresAsExcludes For the sake of a predictable build (ie: making sure this breaks when it's broken), we'll need to either include .gitignore within the .tar.gz, or disable parsing of .gitignore by RAT. My preference would be for the former. >>> Second - JavaScript libraries. I’m not sure what other projects do, but >>> personally I’m not comfortable with distributing libraries in the source >>> distribution. In fact, I’m not a fan of having them in source control. >>> Would it be possible to assemble them into the binary at build time? I’m >>> pretty sure there are artifacts in Maven Central for Angular and JQuery - >>> certainly something like Bower should be an option if not? >>> >> >> I'm not a fan of including them in the source distribution either. If >> they are included in Maven Central, then I see no reason why we can't >> migrate to doing that. I expect migrating to an entirely different >> build system like Bower would be infeasible, unless there is a means >> of integrating it cleanly with Maven (I have not looked into this). > > I don’t think that’s a blocker, (although other IPMC members might). So, it > would be great to look into this for the next release. However, if we leave > the components in, we’ll need to update the LICENSE file. I stand to be > corrected, but I don’t think the MIT license requires anything in the NOTICE > file, nor does the font license, at least from my quick read of it. I'm looking into packaging the JavaScript libraries via Maven now. It's not painless, but it should be doable. >> >>> Third - licensing - The LICENSE file should include all the licenses that >>> apply, not just the Apache license. The idea is to give a downstream user >>> a clear overview of what obligations they’re taking on. I believe I’ve >>> seen a “Guide to constructing LICENSE and NOTICE”, but I don’t have it >>> handy right now. >>> >> >> Are you referring to >> http://www.apache.org/dev/licensing-howto.html#assembling-license-and-notice >> ? >> > > That’s the one! > >> My understanding is that the LICENSE file needs to contain the >> licenses of bundled dependencies. If we remove the bundled JavaScript >> libraries, relying instead on Maven, I believe that would mostly >> resolve this, correct? Outside of those libraries, I believe the only >> bundled dependency is a font under SIL Open Font License (the >> "Carlito" font). >> > > License file still needs to be accurate in the “convenience binary”, so yes, > you’ll need to update. That leads to the odd situation of having different > LICENSE and NOTICE files in the source and binary distributions, but > unfortunately, it is what it is. It’s probably the most common reason for > ‘-1’ votes on incubator releases. > I'll open an issue to get started on this, too. > >>> Good start! >>> >> >> Thanks! ... but then ... -1? +1? Excluding the issues you mention >> regarding RAT, which I believe are false positives, are you saying >> that we need another RC to address the above? >> >> - Mike > > -1 (sorry). But so so close - from what we discussed above, I think just the > license files need updating for now. Getting the javascript libraries out > can wait for later. > Makes sense. We'll get started on the suffering, and begin another RC once enough pain has been endured. > Another thing you’ll want to deal with - is the next release candidate called > 0.9.10 or 0.9.11? I think the Maven ecosystem is happiest if you move on to > 0.9.11 (and put in the release notes that 0.9.10 was skipped), but there are > a variety of opinions on that (to put it mildly). It’s up to the PMC to > decide on a policy. > The next release candidate is 0.9.10. Once the decision to cut a release candidate is made, we create a "staging/{VERSION}" branch, tag the relevant repositories with "{VERSION}-RC1", and deploy artifacts to SVN and a staging Maven repository. As RC1 is being rolled back in this case, we'll simply drop the staging repository, address the above issues, and begin again with a "{VERSION}-RC2" tag. When eventually the RC is approved, we'll merge and delete the "staging/{VERSION}" branch, create a final "{VERSION}" tag, and promote the staging Maven repository. It's only at this point that the Maven ecosystem would be affected. - Mike
