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