incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: [VOTE] Apache Beam release 0.3.0-incubating
Date Sat, 29 Oct 2016 06:16:51 GMT
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 <dhalperi@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
><justin@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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>

Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message