Ah yes that's it. So it's not a project specific thing IMHO. Regards JB
On Oct 29, 2016, 08:15, at 08:15, Christopher <ctubb...@apache.org> wrote: >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 >> > >> > >>
