Hi Attila,
I have given you access to modify Jenkins build jobs.
Please go ahead and make necessary changes.
Thanks,
Yusaku
On 3/6/18, 11:26 AM, "Doroszlai, Attila" wrote:
Yusaku, could you please make the change, or ask someone with access
to Jenkins to do it?
Yusaku, could you please make the change, or ask someone with access
to Jenkins to do it?
Thanks.
-Attila
On Thu, Feb 15, 2018 at 5:27 PM, Jonathan Hurley
wrote:
> +1 as well.
>
> Could we also set a property so that it doesn't try to weave every since
> class? Can we
0 - I’m indifferent to this, but would like to understand the need. Is this
to gain convenience for equals(), hashCode(), toString() and the like or does
Ambari face a real problem that this is addressing?
On 3/3/18, 7:17 AM, "Balazs Bence Sari" wrote:
+1
0 - I am indifferent as well, but I remain cautious about integrating 3rd party
build assistants into our ecosystem. Unlike using a library, this is something
that is required for our IDEs to be compatible with. A change to an IDE or even
JDK version could potentially cause the JAR to no longer
I lean towards -1 a bit. It looks to me that this tool solves a not too
difficult problem but solves it in a not too ideal way. And it’s hard to
predict what will be the implications of using this in the long run.
Builders can be generated by IntelliJ or written by hand quite easily. Although
-1.
I hate to squash other engineers ideas, but it seems that the advantages this
package brings to the table does not outweigh the disadvantages. I agree with
others that posts to this thread about requiring an IDE to rely on a
third-party tool to generate code. If something breaks, we are
I would say go ahead and remove them with no claims.
On 3/5/18, 4:05 PM, "Jonathan Hurley" wrote:
Anyone want to claim these branches? If not, I'd like to remove them.
> On Feb 27, 2018, at 9:48 AM, Jonathan Hurley
wrote:
>