I also did an apache github query
select count(*) as apache_projects, sum(uses_maven=true) as
uses_maven, sum(uses_gradle=true) as uses_gradle from (
select
repo_name,
max(path contains 'pom.xml') as uses_maven,
max(path contains 'gradle') as uses_gradle
from [bigquery-public-data:github_repos.files]
where instr(repo_name, 'apache/') == 1
group by repo_name);
Of 425 total apache projects on gitub, just over half (249) use maven,
and only 25 use gradle. So we'd be in the minority, but certainly not
alone.
I don't think we need to use the most common tool, rather we should
use what fits the project well, and the popularity criteria is simply
that we don't want to choose a tool where obscurity would be a
hinderance. Both gradle and maven seem to clear this bar (as do a host
of others that are even more popular, but would be unsuitable for
other reasons, e.g. plain old make).
We would certainly not switch over to gradle if we couldn't do a
release. IIRC, there's still some work to be done to push this
through, but at this point it doesn't seem like there's any reason to
expect it couldn't be done.
Is there any more data that should be gathered before a vote? (Or
should the vote perhaps have a "+/-0, need more information [please
provide details]" option.)
On Tue, Nov 28, 2017 at 9:45 AM, Scott Wegner <sweg...@google.com> wrote:
> To add one more data point measuring general adoption of gradle vs. maven,
> we can look at Stackoverflow trends comparing the two tags [1]. This shows
> the percentage of new SO questions in a given month by tag. 'gradle'
> represents ~0.25% of questions, while maven is ~0.45%. So, maven is more
> dominant in the Stackoverflow community, but they are at least similar
> orders of magnitude. Also, the data is a bit noisy to draw a trendline, but
> it seems that maven's growth has flattened while gradle is still increasing.
>
> [1] https://insights.stackoverflow.com/trends?tags=maven%2Cgradle
>
> On Tue, Nov 28, 2017 at 9:14 AM Kenneth Knowles <k...@google.com> wrote:
>>
>> Yea, I think voting is the next step. Luke - I think you are obviously the
>> right person to set up the email of what exactly we are voting on, since
>> you've driven this improvement.
>>
>> On Tue, Nov 28, 2017 at 12:08 AM, Robert Bradshaw <rober...@google.com>
>> wrote:
>>>
>>> It's great to see all the discussion going on here.
>>>
>>> I think it's important to point out that merging a parallel set of
>>> gradle build scripts is a separate (and much less disruptive) step
>>> than, say, switching over the default (or even recommended)
>>> build/release process to use them, let alone removing the maven build
>>> files entirely. The latter two should definitely be gated by a formal
>>> vote (each, probably), with the current state the gradle files can
>>> mostly be ignored by most people. In particular, this is the kind of
>>> change that needs to be in master to be evaluated--if it's on a branch
>>> we can't very well see how it impacts presubmits, and most importantly
>>> people can't try it out for real development.
>>>
>>> I agree that the choice of build tool may attract some contributors
>>> and discourage others. Having builds that are fast, correct, and
>>> reproducible will probably matter more to potential contributors than
>>> the particular command to run. While maven can surely be improved, I
>>> doubt a 2x improvement (and many more times that for incremental
>>> builds) is low-hanging fruit, and many of the issues seem quite
>>> fundamental (e.g. all the special treatment we need for NeedsRunner
>>> tests, and having to do a (global-by-default) mvn install to skip
>>> tests of dependencies when testing a leaf module).
>>>
>>> Getting data on what other apache projects use could be interesting,
>>> but unless we gather why such choices were made I don't know that it'd
>>> be that influential once we've established that both tools are widely
>>> supported generally.
>>>
>>> To re-emphasize, we'll continue to produce and publish maven
>>> artifacts, so our choice of build system won't matter for those only
>>> using Beam as a dependency.
>>>
>>>
>>>
>>> On Mon, Nov 27, 2017 at 10:48 PM, Jean-Baptiste Onofré <j...@nanthrax.net>
>>> wrote:
>>> > Yeah, especially, I think it would have been great to have a vote
>>> > before
>>> > merging on master.
>>> >
>>> > Not a big deal, however, I'm really community focus ;)
>>> >
>>> > Regards
>>> > JB
>>> >
>>> > On 11/28/2017 07:36 AM, Reuven Lax wrote:
>>> >>
>>> >> Agreed. I thinking having a formal vote before Luke had numbers and
>>> >> results would have been too early. However now that we have such
>>> >> numbers, we
>>> >> should think about having a vote.
>>> >>
>>> >> Also, while I disagree with Romain that Gradle is not "enterprise
>>> >> ready"
>>> >> (it's heavily used by Netflix, LinkedIn, Siemens, and is the default
>>> >> build
>>> >> framework for Android apps), it would be interesting to see if any
>>> >> other ASF
>>> >> projects are using it. I don't think that should not make or break the
>>> >> decision - we should do what's best for the Beam project, and
>>> >> "everyone else
>>> >> is doing something" is rarely a good argument - it will provide good
>>> >> data
>>> >> points for us to evaluate.
>>> >>
>>> >> Reuven
>>> >>
>>> >> On Mon, Nov 27, 2017 at 10:23 PM, Jean-Baptiste Onofré
>>> >> <j...@nanthrax.net
>>> >> <mailto:j...@nanthrax.net>> wrote:
>>> >>
>>> >> Hi Luke,
>>> >>
>>> >> just curious (and maybe I missed it): did we do a formal vote to
>>> >> merge
>>> >> the
>>> >> gradle build ?
>>> >> Gradle is now on master, we have some Jira to update the release
>>> >> guide
>>> >> with
>>> >> gradle. It's fine, but I remember only a discussion, not a vote.
>>> >>
>>> >> In order to embrace the community and avoid to have some
>>> >> contributors
>>> >> "frustrated" (meaning that "this project doesn't care about
>>> >> contributor,
>>> >> they just do whatever they want"), I would have love to see a
>>> >> formal
>>> >> vote
>>> >> about Gradle more than just a discussion.
>>> >>
>>> >> My $0.01
>>> >>
>>> >> Regards
>>> >> JB
>>> >>
>>> >> On 11/27/2017 07:46 PM, Lukasz Cwik wrote:
>>> >>
>>> >> I have collected data by running several builds against master
>>> >> using Gradle
>>> >> and Maven without using Gradle's support for incremental
>>> >> builds.
>>> >>
>>> >> Gradle (mins)
>>> >> min: 25.04
>>> >> max: 160.14
>>> >> median: 45.78
>>> >> average: 52.19
>>> >> stdev: 30.80
>>> >>
>>> >> Maven (mins)
>>> >> min: 56.86
>>> >> max: 216.55 (actually > 240 mins because this data does not
>>> >> include
>>> >> timeouts)
>>> >> median: 87.93
>>> >> average: 109.10
>>> >> stdev: 48.01
>>> >>
>>> >> I excluded a few timeouts (240 mins) that happened during the
>>> >> Maven build
>>> >> from its numbers but we can see conclusively that Gradle is
>>> >> twice
>>> >> as fast
>>> >> for the build when compared to Maven when run using Jenkins.
>>> >> On my desktop, I have enabled incremental builds and have seen
>>> >> a
>>> >> major
>>> >> improvement on the above numbers but it doesn't yet work
>>> >> correctly
>>> >> because
>>> >> of incorrectly specified inputs/outputs for certain tasks.
>>> >>
>>> >> The data is available here
>>> >>
>>> >>
>>> >> https://docs.google.com/spreadsheets/d/1MHVjF-xoI49_NJqEQakUgnNIQ7Qbjzu8Y1q_h3dbF1M/edit?usp=sharing
>>> >>
>>> >>
>>> >> <https://docs.google.com/spreadsheets/d/1MHVjF-xoI49_NJqEQakUgnNIQ7Qbjzu8Y1q_h3dbF1M/edit?usp=sharing>
>>> >>
>>> >> With this data, I feel confident that we should swap and have
>>> >> opened the
>>> >> following issue
>>> >> https://issues.apache.org/jira/browse/BEAM-3249
>>> >> <https://issues.apache.org/jira/browse/BEAM-3249> and related
>>> >> sub-tasks.
>>> >>
>>> >> On Sun, Nov 19, 2017 at 11:23 AM, Jean-Baptiste Onofré
>>> >> <j...@nanthrax.net
>>> >> <mailto:j...@nanthrax.net>>
>>> >> wrote:
>>> >>
>>> >> Thanks for the update Luke.
>>> >>
>>> >> I'm updating my local working copy to do new tests.
>>> >>
>>> >> Regards
>>> >> JB
>>> >>
>>> >> On 11/19/2017 08:21 PM, Lukasz Cwik wrote:
>>> >>
>>> >> The gradle build rules have been merged, I'm adding a
>>> >> precommit[1] to
>>> >> start
>>> >> collecting data about the build times. It currently
>>> >> only
>>> >> mirrors
>>> >> the Java
>>> >> mvn install precommit. I'll gather data over the next
>>> >> two
>>> >> weeks and
>>> >> provide
>>> >> a summary here.
>>> >>
>>> >> You can rerun the precommit by issuing "Run Java
>>> >> Gradle
>>> >> PreCommit"
>>> >>
>>> >> 1: https://github.com/apache/beam/pull/4146
>>> >> <https://github.com/apache/beam/pull/4146>
>>> >>
>>> >>
>>> >> On Mon, Nov 13, 2017 at 9:08 AM, Lukasz Cwik
>>> >> <lc...@google.com
>>> >> <mailto:lc...@google.com>> wrote:
>>> >>
>>> >> There has been plenty of time for comments on the PR
>>> >> and
>>> >> the
>>> >> approach.
>>> >>
>>> >>
>>> >> So far Ken Knowles has provided the most feedback
>>> >> on
>>> >> the PR,
>>> >> Ken would
>>> >> you
>>> >> like to finish the review?
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Nov 10, 2017 at 1:22 PM, Romain
>>> >> Manni-Bucau <
>>> >> rmannibu...@gmail.com
>>> >> <mailto:rmannibu...@gmail.com>
>>> >>
>>> >> wrote:
>>> >>
>>> >>
>>> >> This is only a setup thing and better to not break
>>> >> the
>>> >> master history for
>>> >>
>>> >> poc/tests, in particular when no very
>>> >> localized.
>>> >> Alternative can be to
>>> >> ask
>>> >> another temp repo to infra and have a synchro
>>> >> between
>>> >> both but dont
>>> >> think
>>> >> it does worth it personally.
>>> >>
>>> >>
>>> >>
>>> >> Le 10 nov. 2017 18:57, "Lukasz Cwik"
>>> >> <lc...@google.com.invalid> a
>>> >> écrit :
>>> >>
>>> >> The reason to get it on master is because that
>>> >> is
>>> >> where
>>> >> all the PRs
>>> >>
>>> >>
>>> >> are. An
>>> >>
>>> >> upstream branch without any development
>>> >> means
>>> >> no data.
>>> >> Also, our Jenkins setup via job-dsl
>>> >> doesn't
>>> >> honor
>>> >> using the Jenkins
>>> >> configuration on the branch because the
>>> >> seed
>>> >> job
>>> >> always runs against
>>> >> master.
>>> >>
>>> >> On Thu, Nov 9, 2017 at 9:59 PM, Romain
>>> >> Manni-Bucau <
>>> >>
>>> >> rmannibu...@gmail.com
>>> >> <mailto:rmannibu...@gmail.com>>
>>> >>
>>> >> wrote:
>>> >>
>>> >> What about pushing it on a "upstream"
>>> >> branch
>>> >> and
>>> >> testing it for 1
>>> >>
>>> >>
>>> >> week in
>>> >>
>>> >>
>>> >> parallel of the maven reference build? If
>>> >> gradle is
>>> >> always 50% faster
>>> >>
>>> >>
>>> >> on
>>> >>
>>> >>
>>> >> jenkins then it could become master setup
>>> >> without
>>> >> much discussion I
>>> >>
>>> >>
>>> >> guess.
>>> >>
>>> >> We can even have 2 jenkins jobs: one
>>> >> with
>>> >> the
>>> >> daemon etc and one
>>> >>
>>> >> without.
>>> >>
>>> >>
>>> >>
>>> >> Also noticed yesterday that gradle
>>> >> build
>>> >> is
>>> >> killing my machine (all 8
>>> >>
>>> >> cores
>>> >>
>>> >> are 100%) during the first minutes vs
>>> >> maven
>>> >> build which let me do
>>> >>
>>> >> something
>>> >>
>>> >> else. Then all the consumed time which
>>> >> makes
>>> >> gradle not that fast is
>>> >>
>>> >> about
>>> >>
>>> >> python. Will try to send figures later
>>> >> today.
>>> >>
>>> >> Le 10 nov. 2017 00:10, "Lukasz Cwik"
>>> >> <lc...@google.com.invalid> a
>>> >>
>>> >> écrit
>>> >>
>>> >>
>>> >> :
>>> >>
>>> >>
>>> >> I wouldn't mind merging this change in
>>> >> so
>>> >> I
>>> >> could setup those Gradle
>>> >>
>>> >> Jenkins precommits.
>>> >>
>>> >> As per our contribution
>>> >> guidelines,
>>> >> any
>>> >> committer willing to sign
>>> >>
>>> >> off
>>> >>
>>> >>
>>> >> on
>>> >>
>>> >> the PR?
>>> >>
>>> >>
>>> >> On Thu, Nov 9, 2017 at 2:12 PM,
>>> >> Romain
>>> >> Manni-Bucau <
>>> >>
>>> >> rmannibu...@gmail.com
>>> >> <mailto:rmannibu...@gmail.com>>
>>> >>
>>> >> wrote:
>>> >>
>>> >> Le 9 nov. 2017 21:31, "Kenneth
>>> >> Knowles"
>>> >> <k...@google.com.invalid>
>>> >>
>>> >>
>>> >> a
>>> >>
>>> >>
>>> >> écrit :
>>> >>
>>> >>
>>> >>
>>> >> Keep in mind that a clean
>>> >> build is
>>> >> unusual during development (it
>>> >>
>>> >> is
>>> >>
>>> >>
>>> >> common
>>> >>
>>> >>
>>> >> for mvn use and that is a bug)
>>> >> and
>>> >> also
>>> >> not necessary for
>>> >>
>>> >> precommits
>>> >>
>>> >>
>>> >> if
>>> >>
>>> >> the
>>> >>
>>> >>
>>> >> build tool is correct enough
>>> >> that
>>> >> caching is safe. So while this
>>> >>
>>> >> number
>>> >>
>>> >>
>>> >> matters, it is not the most important.
>>> >>
>>> >>
>>> >>
>>> >> Not sure, in dev you bypass
>>> >> the
>>> >> build
>>> >> tool most of the time
>>> >>
>>> >> anyway -
>>> >>
>>> >>
>>> >> thanks
>>> >>
>>> >>
>>> >> to IDE or other shortcuts -
>>> >> but
>>> >> not on
>>> >> PR and CI. Keep in mind
>>> >>
>>> >> that
>>> >>
>>> >>
>>> >> not
>>> >>
>>> >> doing a clean and killing gradle
>>> >> daemon
>>> >> makes
>>> >> the build not
>>> >>
>>> >>
>>> >> reproducible
>>> >>
>>> >>
>>> >> and therefore useful :(. Starting
>>> >> to
>>> >> build
>>> >> from a subpart of the
>>> >>
>>> >>
>>> >> reactor
>>> >>
>>> >>
>>> >> -
>>> >>
>>> >> with the mentionned mvn plugin
>>> >> for
>>> >> instance - can be nice on some
>>> >>
>>> >> CI
>>> >>
>>> >>
>>> >> like
>>> >>
>>> >>
>>> >> travis if the caching is well
>>> >> configured but
>>> >> still not a guarantee
>>> >>
>>> >>
>>> >> the
>>> >>
>>> >>
>>> >> build is "green".
>>> >>
>>> >>
>>> >> My trade off is to ensure an
>>> >> easy
>>> >> build
>>> >> and relevant result over
>>> >>
>>> >> the
>>> >>
>>> >>
>>> >> time
>>> >>
>>> >>
>>> >> criteria. Do you share it as well
>>> >> or
>>> >> prefer
>>> >> time over other
>>> >>
>>> >>
>>> >> criteria
>>> >>
>>> >>
>>> >> -
>>> >>
>>> >> which leads to other conclusions and
>>> >> options
>>> >> indeed and can make
>>> >>
>>> >>
>>> >> us
>>> >>
>>> >>
>>> >> not
>>> >>
>>> >> understanding each other?
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Nov 9, 2017 at 11:30
>>> >> AM,
>>> >> Romain
>>> >> Manni-Bucau <
>>> >>
>>> >> rmannibu...@gmail.com
>>> >> <mailto:rmannibu...@gmail.com>
>>> >>
>>> >>
>>> >> wrote:
>>> >>
>>> >>
>>> >> I will try next week yes but
>>> >> the 2
>>> >> runs
>>> >> i did were 28mn vs 32mn
>>> >>
>>> >>
>>> >> from
>>> >>
>>> >>
>>> >> memory
>>> >>
>>> >>
>>> >> - after having downloaded
>>> >> all
>>> >> deps once.
>>> >>
>>> >> Le 9 nov. 2017 19:45,
>>> >> "Lukasz
>>> >> Cwik"
>>> >> <lc...@google.com.invalid>
>>> >>
>>> >> a
>>> >>
>>> >>
>>> >> écrit :
>>> >>
>>> >>
>>> >>
>>> >> If Gradle was slow, do you
>>> >> mind
>>> >> running the build with
>>> >>
>>> >>
>>> >> --profile
>>> >>
>>> >>
>>> >> and
>>> >>
>>> >>
>>> >> sharing that and also sharing the
>>> >> Maven
>>> >> build log?
>>> >>
>>> >>
>>> >> On Thu, Nov 9, 2017 at
>>> >> 10:43 AM,
>>> >> Lukasz Cwik <
>>> >>
>>> >> lc...@google.com
>>> >> <mailto:lc...@google.com>>
>>> >>
>>> >>
>>> >> wrote:
>>> >>
>>> >>
>>> >>
>>> >> Romain, I don't
>>> >> understand
>>> >> your
>>> >> last comment, were you
>>> >>
>>> >>
>>> >> trying
>>> >>
>>> >>
>>> >> to
>>> >>
>>> >> say
>>> >>
>>> >>
>>> >> that
>>> >>
>>> >>
>>> >> you had the same
>>> >> Gradle
>>> >> build
>>> >> times like I did and
>>> >> it
>>> >> was an
>>> >>
>>> >>
>>> >> improvement
>>> >>
>>> >>
>>> >> over Maven or that you
>>> >> did
>>> >> not
>>> >> and you experienced
>>> >> build
>>> >>
>>> >>
>>> >> times
>>> >>
>>> >>
>>> >> that
>>> >>
>>> >>
>>> >> were
>>> >>
>>> >>
>>> >> equivalent to Maven?
>>> >>
>>> >>
>>> >> On Thu, Nov 9,
>>> >> 2017 at
>>> >> 9:51
>>> >> AM, Romain
>>> >> Manni-Bucau
>>> >> <
>>> >>
>>> >> rmannibu...@gmail.com
>>> >>
>>> >> <mailto:rmannibu...@gmail.com>>
>>> >>
>>> >> wrote:
>>> >>
>>> >> 2017-11-09 18:38
>>> >> GMT+01:00
>>> >> Kenneth Knowles
>>> >>
>>> >>
>>> >>
>>> >> <k...@google.com.invalid
>>> >>
>>> >>
>>> >> :
>>> >>
>>> >>
>>> >> On Thu, Nov 9, 2017 at
>>> >> 9:11 AM,
>>> >> Romain Manni-Bucau <
>>> >>
>>> >>
>>> >>
>>> >> rmannibu...@gmail.com
>>> >>
>>> >> <mailto:rmannibu...@gmail.com>>
>>> >>
>>> >> wrote:
>>> >>
>>> >> (this is
>>> >> another
>>> >> topic so
>>> >> we
>>> >> can
>>> >> maybe open
>>> >> another
>>> >>
>>> >>
>>> >> thread)
>>> >>
>>> >>
>>> >> issue
>>> >>
>>> >>
>>> >> is
>>> >>
>>> >>
>>> >> not much about python
>>> >> but
>>> >> more
>>> >> about the fact the
>>> >> build
>>> >>
>>> >>
>>> >> is
>>> >>
>>> >>
>>> >> not
>>> >>
>>> >>
>>> >> self
>>> >>
>>> >>
>>> >> contained. it is a maven
>>> >> build
>>> >> and
>>> >> maven should be
>>> >>
>>> >>
>>> >> sufficient
>>> >>
>>> >>
>>> >> without
>>> >>
>>> >>
>>> >> having to install
>>> >> python +
>>> >> dependencies.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Let's
>>> >> leave
>>> >> out the
>>> >> topic of
>>> >> whether our
>>> >> build
>>> >> should
>>> >>
>>> >> install
>>> >>
>>> >>
>>> >> things
>>> >>
>>> >>
>>> >> like
>>> >>
>>> >>
>>> >> JDKs,
>>> >> Python,
>>> >> Golang,
>>> >> Docker,
>>> >> protoc,
>>> >> findbugs,
>>> >> RAT, etc.
>>> >>
>>> >> That
>>> >>
>>> >>
>>> >> issue
>>> >>
>>> >>
>>> >> is
>>> >>
>>> >>
>>> >> somewhat
>>> >> independent
>>> >> of
>>> >> build tool, and
>>> >> the
>>> >> new build
>>> >>
>>> >>
>>> >> isn't
>>> >>
>>> >>
>>> >> worse
>>> >>
>>> >>
>>> >> than
>>> >>
>>> >>
>>> >> the
>>> >>
>>> >>
>>> >> old one as
>>> >> far
>>> >> as it
>>> >> goes.
>>> >>
>>> >>
>>> >>
>>> >> Yep, globally
>>> >> the
>>> >> same
>>> >> time with
>>> >> clean
>>> >> and
>>> >> killing the
>>> >>
>>> >> daemon.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Kenn
>>> >>
>>> >>
>>> >>
>>> >> I don't
>>> >> see
>>> >> any
>>> >> technical
>>> >>
>>> >>
>>> >> blockers
>>> >> to do
>>> >> it
>>> >> (except
>>> >> time
>>> >> ;))
>>> >> but it
>>> >> is
>>> >> always
>>> >> a
>>> >>
>>> >> bit
>>> >>
>>> >>
>>> >> annoying
>>> >>
>>> >>
>>> >> to
>>> >>
>>> >> git clone then not be
>>> >> able
>>> >> to build.
>>> >>
>>> >>
>>> >> Romain
>>> >> Manni-Bucau
>>> >>
>>> >> @rmannibucau |
>>> >> Blog | Old Blog
>>> >> |
>>> >> Github |
>>> >> LinkedIn
>>> >>
>>> >>
>>> >>
>>> >> 2017-11-09
>>> >> 18:07
>>> >>
>>> >> GMT+01:00
>>> >> Lukasz
>>> >> Cwik
>>> >>
>>> >>
>>> >> <lc...@google.com.invalid
>>> >>
>>> >>
>>> >> :
>>> >>
>>> >>
>>> >> Hmm, I have had good
>>> >> luck
>>> >> when
>>> >> following the Python
>>> >>
>>> >>
>>> >> quick
>>> >>
>>> >>
>>> >> start
>>> >>
>>> >>
>>> >> setup
>>> >>
>>> >>
>>> >>
>>> >> <https://beam.apache.org/get-started/quickstart-py/
>>> >>
>>> >> <https://beam.apache.org/get-started/quickstart-py/>>
>>> >>
>>> >>
>>> >> on
>>> >>
>>> >>
>>> >> multiple
>>> >>
>>> >>
>>> >> machines
>>> >>
>>> >>
>>> >> by
>>> >> ensuring
>>> >>
>>> >> the
>>> >>
>>> >> installed
>>> >>
>>> >> version of
>>> >>
>>> >> setuptools,
>>> >>
>>> >>
>>> >> virtualenv
>>> >>
>>> >>
>>> >> and
>>> >>
>>> >>
>>> >> pip
>>> >>
>>> >>
>>> >> are
>>> >>
>>> >>
>>> >> new
>>> >>
>>> >>
>>> >>
>>> >> enough
>>> >> versions.
>>> >>
>>> >>
>>> >> You
>>> >> can
>>> >>
>>> >> always
>>> >> skip
>>> >>
>>> >> the
>>> >> Python
>>> >>
>>> >> portion of
>>> >>
>>> >> the
>>> >> build by
>>> >>
>>> >>
>>> >> excluding
>>> >>
>>> >>
>>> >> the
>>> >>
>>> >>
>>> >> build
>>> >>
>>> >>
>>> >>
>>> >> task
>>> >> as so:
>>> >>
>>> >> ./gradlew
>>> >>
>>> >> build
>>> >> -x
>>> >>
>>> >> ":beam-sdks-parent:beam-sdks-
>>> >>
>>> >>
>>> >> python:build"
>>> >>
>>> >>
>>> >>
>>> >> On
>>> >> Thu, Nov
>>> >> 9,
>>> >> 2017 at
>>> >>
>>> >> 8:58
>>> >> AM,
>>> >>
>>> >> Romain
>>> >>
>>> >> Manni-Bucau <
>>> >>
>>> >>
>>> >> rmannibu...@gmail.com
>>> >>
>>> >> <mailto:rmannibu...@gmail.com>>
>>> >>
>>> >>
>>> >> wrote:
>>> >>
>>> >>
>>> >> The
>>> >> 1.3.5
>>> >>
>>> >> file
>>> >> is when
>>> >> i
>>> >> installed
>>> >>
>>> >> the
>>> >> python
>>> >>
>>> >>
>>> >>
>>> >> dependencies
>>> >>
>>> >>
>>> >> manually
>>> >>
>>> >>
>>> >> to make the build
>>> >> passing
>>> >> (the pip command
>>> >> never
>>> >>
>>> >>
>>> >>
>>> >> passed
>>> >>
>>> >>
>>> >> on
>>> >>
>>> >> my
>>> >>
>>> >>
>>> >> computer
>>> >>
>>> >>
>>> >> and
>>> >> therefore
>>> >> the
>>> >> build
>>> >> always
>>> >> has
>>> >> been
>>> >> broken
>>> >> until
>>> >>
>>> >>
>>> >> i
>>> >>
>>> >>
>>> >> installed
>>> >>
>>> >>
>>> >> it
>>> >>
>>> >>
>>> >> manually -
>>> >> independently
>>> >> from the build
>>> >> tool).
>>> >>
>>> >>
>>> >>
>>> >> Romain
>>> >>
>>> >> Manni-Bucau
>>> >>
>>> >> @rmannibucau
>>> >>
>>> >> |
>>> >> Blog
>>> >>
>>> >> |
>>> >> Old
>>> >>
>>> >> Blog |
>>> >>
>>> >> Github |
>>> >>
>>> >> LinkedIn
>>> >>
>>> >>
>>> >>
>>> >> 2017-11-09
>>> >>
>>> >> 17:51
>>> >>
>>> >> GMT+01:00 Lukasz
>>> >>
>>> >> Cwik
>>> >>
>>> >>
>>> >> <lc...@google.com.invalid
>>> >>
>>> >>
>>> >> :
>>> >>
>>> >>
>>> >> It turns out
>>> >> that
>>> >> the
>>> >> Apache Rat Ant
>>> >> task and the
>>> >>
>>> >>
>>> >>
>>> >> Apache
>>> >>
>>> >>
>>> >> Rat
>>> >>
>>> >>
>>> >> Maven
>>> >>
>>> >>
>>> >> plugin
>>> >>
>>> >>
>>> >>
>>> >> differ
>>> >> in
>>> >>
>>> >> that
>>> >> the
>>> >>
>>> >> plugin
>>> >>
>>> >> automatically excludes
>>> >>
>>> >>
>>> >>
>>> >> certain
>>> >>
>>> >>
>>> >> files
>>> >>
>>> >>
>>> >> by
>>> >>
>>> >>
>>> >> default
>>> >>
>>> >>
>>> >>
>>> >> while
>>> >> the
>>> >>
>>> >> Ant
>>> >> task
>>> >>
>>> >> does
>>> >> not.
>>> >>
>>> >>
>>> >> See:
>>> >>
>>> >> http://creadur.apache.org/rat/
>>> >>
>>> >>
>>> >> apache-rat-plugin/check-mojo.
>>> >>
>>> >>
>>> >> html#useDefaultExcludes
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> I
>>> >>
>>> >> fixed the
>>> >>
>>> >> list
>>> >>
>>> >> to
>>> >>
>>> >> exclude
>>> >>
>>> >> ".idea/"
>>> >>
>>> >> instead
>>> >>
>>> >> of
>>> >>
>>> >>
>>> >> "idea/"
>>> >>
>>> >>
>>> >> since
>>> >>
>>> >>
>>> >> there
>>> >>
>>> >>
>>> >> was a
>>> >>
>>> >>
>>> >>
>>> >> typo.
>>> >>
>>> >>
>>> >>
>>> >> I
>>> >>
>>> >> have
>>> >>
>>> >> no
>>> >>
>>> >> idea
>>> >>
>>> >> what
>>> >>
>>> >> the
>>> >>
>>> >> file
>>> >>
>>> >> "=1.3.5"
>>> >>
>>> >> is.
>>> >>
>>> >> Can you
>>> >>
>>> >>
>>> >> take a
>>> >>
>>> >>
>>> >> look
>>> >>
>>> >>
>>> >> at
>>> >>
>>> >> the
>>> >>
>>> >>
>>> >> contents?
>>> >>
>>> >>
>>> >>
>>> >> On
>>> >>
>>> >> Thu,
>>> >>
>>> >> Nov
>>> >>
>>> >> 9,
>>> >>
>>> >> 2017
>>> >>
>>> >> at
>>> >>
>>> >> 12:03 AM,
>>> >>
>>> >> Romain
>>> >>
>>> >>
>>> >> Manni-Bucau
>>> >>
>>> >> <
>>> >>
>>> >>
>>> >> rmannibu...@gmail.com
>>> >> <mailto:rmannibu...@gmail.com>>
>>> >>
>>> >>
>>> >>
>>> >> wrote:
>>> >>
>>> >>
>>> >> Ok,
>>> >>
>>> >> the
>>> >>
>>> >> rat
>>> >>
>>> >> issues
>>> >>
>>> >> I
>>> >>
>>> >> got
>>> >>
>>> >> were:
>>> >>
>>> >>
>>> >>
>>> >> ==
>>> >>
>>> >> File:
>>> >>
>>> >> /home/rmannibucau/1_dev/beam/.idea/*
>>> >>
>>> >> ==
>>> >>
>>> >> File:
>>> >>
>>> >> /home/rmannibucau/1_dev/beam/
>>> >>
>>> >>
>>> >> sdks/python/=1.3.5
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> The
>>> >>
>>> >> first
>>> >>
>>> >> one
>>> >>
>>> >> could
>>> >>
>>> >> be
>>> >>
>>> >> in
>>> >>
>>> >> my
>>> >>
>>> >> default
>>> >>
>>> >> exclude
>>> >>
>>> >> -
>>> >>
>>> >>
>>> >> even
>>> >>
>>> >>
>>> >> if
>>> >>
>>> >> eclipse/idea
>>> >>
>>> >>
>>> >> files
>>> >> should
>>> >> be in
>>> >> the
>>> >> default
>>> >> exclude
>>> >> set of
>>> >> beam
>>> >>
>>> >>
>>> >>
>>> >> rat
>>> >>
>>> >>
>>> >> config
>>> >>
>>> >>
>>> >> IMHO,
>>> >>
>>> >>
>>> >> the last
>>> >> one
>>> >> is more
>>> >> a "?" can
>>> >> probably be
>>> >>
>>> >>
>>> >>
>>> >> exclude
>>> >>
>>> >> as
>>> >>
>>> >>
>>> >> well
>>> >>
>>> >>
>>> >> if
>>> >>
>>> >> created
>>> >>
>>> >>
>>> >> by the
>>> >> build
>>> >> at some
>>> >> point.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Romain
>>> >>
>>> >> Manni-Bucau
>>> >>
>>> >> @rmannibucau
>>> >>
>>> >> |
>>> >> Blog
>>> >>
>>> >> | Old
>>> >>
>>> >> Blog
>>> >>
>>> >> | Github
>>> >>
>>> >> |
>>> >>
>>> >>
>>> >> LinkedIn
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> 2017-11-08
>>> >>
>>> >> 19:17
>>> >>
>>> >> GMT+01:00
>>> >>
>>> >> Jean-Baptiste
>>> >>
>>> >> Onofré
>>> >>
>>> >> <
>>> >>
>>> >>
>>> >> j...@nanthrax.net
>>> >>
>>> >> <mailto:j...@nanthrax.net>
>>> >>
>>> >>
>>> >> :
>>> >>
>>> >>
>>> >> Thanks
>>> >> for
>>> >> the
>>> >>
>>> >> update. I
>>> >> was
>>> >>
>>> >> swamped on
>>> >> some
>>> >>
>>> >>
>>> >>
>>> >> meetings.
>>> >>
>>> >>
>>> >> I'm
>>> >>
>>> >>
>>> >> back to
>>> >>
>>> >>
>>> >> test
>>> >>
>>> >>
>>> >>
>>> >> the
>>> >>
>>> >> latest
>>> >>
>>> >> changes.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Regards
>>> >>
>>> >> JB
>>
>>
> --
>
>
> Got feedback? http://go/swegner-feedback
