Hi Dan Yeah good catch. Default configuration of the release plugin doesn't create such file afair. So we probably have a configuration or other plugins defined in the project.
Regards JB On Oct 29, 2016, 08:07, at 08:07, Dan Halperin <dhalp...@google.com.INVALID> wrote: >Hi Justin, > >Thanks for excellent detailed analysis, as usual! > >1) Hmm! I do see a file called `DEPENDENCIES` in the source release >[0], >but it is not checked in [1]. It must be introduced somehow by `mvn >release-plugin`, following our release process [2]. >To clear up some possible confusion: We **definitely** run Apache RAT >in >the release profile [3], which is ran continually on every single >commit >[4], and this has indeed caught unlicensed files. [5] Because >DEPENDENCIES >is not under version control but somehow ended up in the source >release, >RAT does not help here. > We'll have to find where in the release process this file was >introduced. This same issue happened in the two prior incubating >releases, >but was not noticed :/. > Hmm! > >[0] >https://dist.apache.org/repos/dist/dev/incubator/beam/0.3.0-incubating/ >[1] >https://github.com/apache/incubator-beam/blob/release-0.3.0-incubating/DEPENDENCIES >(HTTP 404 expected) >[2] http://beam.incubator.apache.org/contribute/release-guide/ >[3] >https://github.com/apache/incubator-beam/blob/release-0.3.0-incubating/pom.xml#L197 >[4] Example: >https://builds.apache.org/job/beam_PreCommit_MavenVerify/4362/org.apache.beam$beam-parent/console > >[5] >https://github.com/apache/incubator-beam/pull/1199/commits/0addd4c7138211cdfb9056101c8e13325ad3de58 > >2) I'm not sure precisely what the definition of `optional` is; I'd >like >some clarification. We do indeed build the module by default, but it is >not >in any way required to use Beam. For example: > Beam's examples [6] module does not depend on Kinesis. This is a key >user starting point -- the examples provide many useful, flagship >end-to-end Beam pipelines. The same goes for our Maven archetypes for >the >examples [7] and starter projects [8]. In fact, no module depends on >the >module that provides Kinesis, explicitly so that it is completely >unused >unless a user opts into it. > >[6] >https://github.com/apache/incubator-beam/blob/release-0.3.0-incubating/examples/pom.xml >[7] >https://github.com/apache/incubator-beam/blob/release-0.3.0-incubating/sdks/java/maven-archetypes/examples/src/main/resources/archetype-resources/pom.xml >[8] >https://github.com/apache/incubator-beam/blob/release-0.3.0-incubating/sdks/java/maven-archetypes/starter/src/main/resources/archetype-resources/pom.xml > >Thanks, >Dan > >On Fri, Oct 28, 2016 at 10:37 PM, Justin Mclean ><jus...@classsoftware.com> >wrote: > >> Hi, >> >> > We discussed about this dependency on the dev mailing list. >> >> Yep I read that discussion and it seems to me to be missing the main >> point. Yes you can’t have Category X software in a release but you >can’t >> have it as a dependancy either unless it’s optional. >> >> > The dependency is not embedded in any Beam distribution or jar >file. The >> users have to explicitly define the dependency to be able to use the >> Kinesis IO. >> >> Which may not be enough IMO. The question to ask is “Will most users >want >> to use Kinesis IO or not?" >> >> Thanks, >> Justin >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >>
