I believe the DEPENDENCIES file is produced by the Apache Parent POM's execution of the maven-remote-resources-plugin, and it is generated when the 'apache-release' profile is active during a release.
On Sat, Oct 29, 2016 at 2:07 AM 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 > > > > >
