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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>

Reply via email to