@Kenneth: this looks like my experience as well but is Idea - not even
speaking of eclipse - that bad with gradle? Thought that it was not since
android picked it up but never managed to make it scale on bigger projects
due to the prebuild phases which are super slow, require a full passing
build (which can be tricky with the native expectations of beam for pyyhon
for instance :() and regular updates when working on new modules in PR.

Anyone knows a way to make it better, and more important, working OOTB
whatever the machine you are using (with gradle/java but not go and with a
bad version of python to take a random example ;))? Does it need a fast
build import or idea meta generation?

Le 7 mars 2018 23:22, "Jason Kuster" <jasonkus...@google.com> a écrit :

> +1
>
>
> On Wed, Mar 7, 2018 at 2:21 PM Robert Bradshaw <rober...@google.com>
> wrote:
>
>> +1 to a fixit day. I'd be happy to help out myself.
>>
>>
>> On Wed, Mar 7, 2018 at 1:49 PM Henning Rohde <hero...@google.com> wrote:
>>
>>> +1 to a Gradle fixit day/week. I agree with Romain that we should make
>>> an effort quit this dual state. The Go, Go PreCommit and various container
>>> image Gradle builds, I think, are in a reasonable state (modulo some
>>> documentation updates).
>>>
>>> On Wed, Mar 7, 2018 at 1:29 PM, Kenneth Knowles <k...@google.com> wrote:
>>>
>>>> SGTM. I should also say that every day is Gradle fixit day for me, as I
>>>> have been using only Gradle (with IntelliJ) for a while :-). If anyone is
>>>> hesitant, definitely it is ready to be used for normal dev.
>>>>
>>>> Seems like changing the messaging in onboarding docs is the main thing
>>>> to fixit.
>>>>
>>>> Based on https://builds.apache.org/view/A-D/view/Beam/ and our failure
>>>> spam level the performance tests are mostly not healthy anyhow. So is there
>>>> any high level blocker to switching them or is it just someone sitting down
>>>> with each one?
>>>>
>>>> Kenn
>>>>
>>>>
>>>> On Wed, Mar 7, 2018 at 1:22 PM Lukasz Cwik <lc...@google.com> wrote:
>>>>
>>>>> Largest outstanding areas are:
>>>>> * Documentation relevant to the contributors guide/release
>>>>> process/testing
>>>>> * Performance tests
>>>>>
>>>>> There has been good progress towards:
>>>>> * Release artifact validations and generation
>>>>> * ValidatesRunner post commits
>>>>> * Pre commits
>>>>> * Container builds
>>>>>
>>>>>
>>>>> On Wed, Mar 7, 2018 at 1:19 PM, Reuven Lax <re...@google.com> wrote:
>>>>>
>>>>>> I think Alan was making progress on the Gradle build.
>>>>>>
>>>>>> What do people think of a "fixit" day for Gradle work? (or given that
>>>>>> people are distributed, maybe a fixit week, where everyone takes one day
>>>>>> from the week).
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 7, 2018 at 1:17 PM Kenneth Knowles <k...@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I also cannot drop everything to work on Gradle build, but maybe it
>>>>>>> isn't that drastic anyhow. Now that we have ValidatesRunner and 
>>>>>>> NeedsRunner
>>>>>>> tests and some progress on the release, is there any other known missing
>>>>>>> functionality in the Gradle builds? Archetypes? Docker container images?
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 7, 2018 at 1:12 PM Lukasz Cwik <lc...@google.com> wrote:
>>>>>>>
>>>>>>>> I am working on various projects and may not be able to pause my
>>>>>>>> work for a couple of weeks while the build/test process is migrated.
>>>>>>>>
>>>>>>>> What is everyone thinking about Romain's suggestion because If I'm
>>>>>>>> the only person in such a situation, I would be willing to go along 
>>>>>>>> with
>>>>>>>> the plan.
>>>>>>>>
>>>>>>>> On Wed, Mar 7, 2018 at 12:59 PM, Romain Manni-Bucau <
>>>>>>>> rmannibu...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 7 mars 2018 20:21, "Lukasz Cwik" <lc...@google.com> a écrit :
>>>>>>>>>
>>>>>>>>> Note that Alan Myrvold has been making steady progress making the
>>>>>>>>> release process via Gradle a reality:
>>>>>>>>> 1) Creating a jenkins job which can run the quickstart validation
>>>>>>>>> against nightly snapshots and also can be used for release candidates 
>>>>>>>>> (
>>>>>>>>> https://github.com/apache/beam/pull/4252)
>>>>>>>>> 2) Building a release candidate using Gradle (
>>>>>>>>> https://github.com/apache/beam/pull/4812)
>>>>>>>>>
>>>>>>>>> Also, Gradle is the tool that has been selected already and there
>>>>>>>>> was a community discussion about what was needed for the migration to 
>>>>>>>>> occur
>>>>>>>>> with a clear set of criteria. Romain, it doesn't seem like we should 
>>>>>>>>> ignore
>>>>>>>>> that criteria or are you suggesting we change that criteria (if yes, 
>>>>>>>>> how)?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, no. My goal is just to quit this state.
>>>>>>>>>
>>>>>>>>> Let s draft a plan:
>>>>>>>>>
>>>>>>>>> 1. 2.4 is released - i assume it is done with mvn here
>>>>>>>>> 2. We drop all poms and jenkins mvn config
>>>>>>>>> 3. We fix all build issues if so (let say in a week)
>>>>>>>>> 4. Pr can nees updates but no more mvn merge
>>>>>>>>>
>>>>>>>>> April is gradle month :)
>>>>>>>>>
>>>>>>>>> Wdyt?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Mar 7, 2018 at 10:39 AM, Romain Manni-Bucau <
>>>>>>>>> rmannibu...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 7 mars 2018 17:34, "Lukasz Cwik" <lc...@google.com> a écrit :
>>>>>>>>>>
>>>>>>>>>> Thanks for bringing this up Romain but I believe your data points
>>>>>>>>>> on pass rates are only partially correct.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sure sure, it is mainly about my own PR which a very small % of
>>>>>>>>>> the whole project ;).
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> In the past week the Java Gradle precommit passed 46.34% of the
>>>>>>>>>> time compared to the Java Maven precommit which passed 46.15% of the 
>>>>>>>>>> time.
>>>>>>>>>> When I looked at these numbers in mid January they were around 37% 
>>>>>>>>>> so there
>>>>>>>>>> has been some improvement. Regardless of the build tool it seems 
>>>>>>>>>> that our
>>>>>>>>>> pass rates aren't stellar for the Java build and are causing the 
>>>>>>>>>> community
>>>>>>>>>> to not follow best practices (wait for precommits to be green before
>>>>>>>>>> merging). I know that on the website we used the mergebot to ensure 
>>>>>>>>>> that
>>>>>>>>>> things passed before they were merged, should we institute this on 
>>>>>>>>>> the
>>>>>>>>>> master branch or are their any other ideas?
>>>>>>>>>>
>>>>>>>>>> As a side note we had achieved the goals we set out to not need
>>>>>>>>>> to maintain the Maven precommit and have authored the first PR to 
>>>>>>>>>> drop the
>>>>>>>>>> Maven precommit:  https://github.com/apache/beam/pull/4814
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Well, I'd be for a strong switch otherwise PR will keep using
>>>>>>>>>> maven, jenkins will not test the code and at the end we fail to 
>>>>>>>>>> deliver
>>>>>>>>>> something consistent. So whatever tool is selected I'm tempted to 
>>>>>>>>>> say drop
>>>>>>>>>> other build files and jenkins hooks references.
>>>>>>>>>>
>>>>>>>>>> What about doing it after 2.4 vote?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Mar 7, 2018 at 2:24 AM, Romain Manni-Bucau <
>>>>>>>>>> rmannibu...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Up,
>>>>>>>>>>>
>>>>>>>>>>> We discussed to have a strong switch to gradle or rollback to
>>>>>>>>>>> maven around april to not be blocked by the build tool. I noticed 
>>>>>>>>>>> gradle
>>>>>>>>>>> build rarely passes on PR and kind of blurry our vision - not sure 
>>>>>>>>>>> why
>>>>>>>>>>> exactly. Also, PR don't always contain the gradle updates - 
>>>>>>>>>>> generally
>>>>>>>>>>> dependencies+plugins are added in pom.xml AFAIK, so it seems the 
>>>>>>>>>>> adoption
>>>>>>>>>>> is very slow to not say rejected.
>>>>>>>>>>>
>>>>>>>>>>> What do we do about that? When do we drop the double build
>>>>>>>>>>> maintenance - whatever is picked?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Romain Manni-Bucau
>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>>>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>>>>>>> <http://rmannibucau.wordpress.com> | Github
>>>>>>>>>>> <https://github.com/rmannibucau> | LinkedIn
>>>>>>>>>>> <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>>>>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>>>>>>>>>>
>>>>>>>>>>> 2018-01-12 6:30 GMT+01:00 Romain Manni-Bucau <
>>>>>>>>>>> rmannibu...@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Le 11 janv. 2018 23:13, "Kenneth Knowles" <k...@google.com> a
>>>>>>>>>>>> écrit :
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jan 11, 2018 at 8:43 AM, Romain Manni-Bucau <
>>>>>>>>>>>> rmannibu...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> 2. gradle build doesn't use the same output directory than
>>>>>>>>>>>>> maven so it is not really smooth to have both and have to 
>>>>>>>>>>>>> maintain both
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I also have an opinion on this. It is useful and reasonable to
>>>>>>>>>>>> be able to build even when the source is on a read-only 
>>>>>>>>>>>> filesystem. Maven's
>>>>>>>>>>>> defaults are undesirable and require workarounds. We shouldn't 
>>>>>>>>>>>> mimic the
>>>>>>>>>>>> behavior, but actually should set gradle up to build to a 
>>>>>>>>>>>> directory outside
>>>>>>>>>>>> the source tree always, if we can.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hmm, which is something you can do with maven as well so not
>>>>>>>>>>>> sure I get it.
>>>>>>>>>>>>
>>>>>>>>>>>> Also note the thread is no more about the technical points but
>>>>>>>>>>>> more the sources maintenance and consistency.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Kenn
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>>
>
> --
> -------
> Jason Kuster
> Apache Beam / Google Cloud Dataflow
>

Reply via email to