Re: [ANNOUNCE] James Turton as PMC Member

[Paul Rogers]

Congratulations James!

- Paul

On Mon, Jan 24, 2022 at 9:34 AM Charles Givre 
wrote:

> The Project Management Committee (PMC) for Apache Drill is pleased to
> announce that we have invited James Turton to join us as a PMC member of
> the Drill project and he has accepted.  Please join me in congratulating
> James and welcoming him to the PMC!
>
>
> Best,
> Charles Givre
> PMC Chair, Apache Drill
>
>
>
>
> Charles Givre
> Founder, CEO DataDistillr
> Email:  char...@datadistillr.com
> Phone:  + 443-762-3286
> Book a Meeting 30 min  • 60
> min 
> LinkedIn @cgivre 
> GitHub @cgivre 
>  
>

Re: [ANNOUNCE] New Committer: PJ Fanning

[Paul Rogers]

Congratulations!

- Paul

On Mon, Jan 24, 2022 at 9:15 AM Charles Givre  wrote:

> The Project Management Committee (PMC) for Apache Drill is pleased to
> announce that we have invited PJ Fanning to join us as a committer to the
> Drill project.  PJ is a committer and PMC member for the Apache POI project
> and author of the Excel Streaming library which Drill uses for the Excel
> reader.  He has contributed numerous fixes and assistance to Drill relating
> to the Drill's Excel reader.  Please join me in congratulating PJ and
> welcoming him as a committer!
>
> Best,
> Charles Givre
> PMC Chair, Apache Drill
>
>

[GitHub] [drill] luocooong commented on pull request #2433: DRILL-8111: Remove lombok usage

[GitBox]

luocooong commented on pull request #2433:
URL: https://github.com/apache/drill/pull/2433#issuecomment-1020723253


   @paul-rogers Could you please take a look? Thank you very much.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] Keynote for Drill meetup

[Jorge Alvarado]

that would be amzing!
I would love to catch up with the discussions even in "asnyc" mode.

thanks

Jorge

From: Jingchuan Hu 
Sent: Monday, January 24, 2022 15:19
To: u...@drill.apache.org 
Cc: dev@drill.apache.org 
Subject: [DISCUSS] Keynote for Drill meetup

Hi team,

I am thinking that we could do screen recording for our each meetup.
1. We could use Zoom built-in screen recording feature directly, and that
needs permission from James.
2. After the meetup, we could summarize the keynote, edit the spotlight of
the meetup, like, the discussion of new version release, idea sharing and
etc.,
3. And we could upload the keynote and spotlight clips to github wiki,
youtube and bilibili (for users and developers from China).
So that we can fully record our meetup history, and it's convenient for new
users to get known about Drill.
If the community thinks that this is worth doing. I am willing to be
responsible for this procedure.
And please provide more suggestions for this idea.

Best,
Jingchuan

Re: [ANNOUNCE] New Committer: PJ Fanning

[James Turton]

Great to have you on board PJ and thank for you for all of your 
contributions to date!


On 2022/01/24 19:15, Charles Givre wrote:

The Project Management Committee (PMC) for Apache Drill is pleased to announce 
that we have invited PJ Fanning to join us as a committer to the Drill project. 
 PJ is a committer and PMC member for the Apache POI project and author of the 
Excel Streaming library which Drill uses for the Excel reader.  He has 
contributed numerous fixes and assistance to Drill relating to the Drill's 
Excel reader.  Please join me in congratulating PJ and welcoming him as a 
committer!

Best,
Charles Givre
PMC Chair, Apache Drill

Re: [ANNOUNCE] New Committer: PJ Fanning

[Z0ltrix]

Congratulations PJ!

Best Regards
Christian

\ Original-Nachricht 
Am 24. Jan. 2022, 18:15, Charles Givre schrieb:

>
>
>
> The Project Management Committee (PMC) for Apache Drill is pleased to 
> announce that we have invited PJ Fanning to join us as a committer to the 
> Drill project. PJ is a committer and PMC member for the Apache POI project 
> and author of the Excel Streaming library which Drill uses for the Excel 
> reader. He has contributed numerous fixes and assistance to Drill relating to 
> the Drill's Excel reader. Please join me in congratulating PJ and welcoming 
> him as a committer!
>
> Best,
> Charles Givre
> PMC Chair, Apache Drill

publickey - EmailAddress(s=z0ltrix@pm.me) - 0xF0E154C5.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

[GitHub] [drill] vvysotskyi opened a new pull request #2433: DRILL-8111: Remove lombok usage

[GitBox]

vvysotskyi opened a new pull request #2433:
URL: https://github.com/apache/drill/pull/2433


   # [DRILL-8111](https://issues.apache.org/jira/browse/DRILL-8111): Remove 
lombok usage
   
   ## Description
   See ticket for details.
   
   ## Documentation
   NA
   
   ## Testing
   NA
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (DRILL-8111) Remove lombok usage

[Vova Vysotskyi (Jira)]

Vova Vysotskyi created DRILL-8111:
-

 Summary: Remove lombok usage
 Key: DRILL-8111
 URL: https://issues.apache.org/jira/browse/DRILL-8111
 Project: Apache Drill
  Issue Type: Task
Affects Versions: 1.20.0
Reporter: Vova Vysotskyi
Assignee: Vova Vysotskyi
 Fix For: 1.20.0


See https://lists.apache.org/thread/gdv21h4m9omoqojhbpc4pcxtmyoqwrm6 for 
details.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: [ANNOUNCE] James Turton as PMC Member

[James Turton]

Thank you kindly Charles!  I look forward to many productive Drill 
projects and lots of time spent interacting with all the talented and 
interesting people in our community.



On 2022/01/24 19:29, Charles Givre wrote:
The Project Management Committee (PMC) for Apache Drill is pleased to 
announce that we have invited James Turton to join us as a PMC member 
of the Drill project and he has accepted.  Please join me in 
congratulating James and welcoming him to the PMC!



Best,
Charles Givre
PMC Chair, Apache Drill



Charles Givre
avatar
Charles Givre
Founder, CEO DataDistillr
Email:
char...@datadistillr.com
Phone:
+ 443-762-3286
GitHubBook a Meeting 30 min 
 • 60 min 


LinkedInLinkedIn @cgivre 
GitHubGitHub @cgivre 
DataDistillr logo 

Re: [ANNOUNCE] James Turton as PMC Member

[Z0ltrix]

Great to hear this...
Congratulations James!

Best Regards,
Christian Original-Nachricht 
Am 24. Jan. 2022, 18:29, Charles Givre schrieb:

>
>
>
> The Project Management Committee (PMC) for Apache Drill is pleased to 
> announce that we have invited James Turton to join us as a PMC member of the 
> Drill project and he has accepted. Please join me in congratulating James and 
> welcoming him to the PMC!
>
>
> Best,
> Charles Givre
> PMC Chair, Apache Drill
>
>
>
>
> Charles Givre
> Founder, CEO DataDistillr
> Email: char...@datadistillr.com
> Phone: + 443-762-3286
> Book a Meeting 30 min  • 60 min 
> 
> LinkedIn @cgivre 
> GitHub @cgivre 
> 
>

publickey - EmailAddress(s=z0ltrix@pm.me) - 0xF0E154C5.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

[ANNOUNCE] James Turton as PMC Member

[Charles Givre]

The Project Management Committee (PMC) for Apache Drill is pleased to announce 
that we have invited James Turton to join us as a PMC member of the Drill 
project and he has accepted.  Please join me in congratulating James and 
welcoming him to the PMC!


Best,
Charles Givre
PMC Chair, Apache Drill 



 
Charles Givre
Founder, CEO DataDistillr
Email:  char...@datadistillr.com
Phone:  + 443-762-3286
Book a Meeting 30 min  • 60 min 

LinkedIn @cgivre 
GitHub @cgivre 
 

[ANNOUNCE] New Committer: PJ Fanning

[Charles Givre]

The Project Management Committee (PMC) for Apache Drill is pleased to announce 
that we have invited PJ Fanning to join us as a committer to the Drill project. 
 PJ is a committer and PMC member for the Apache POI project and author of the 
Excel Streaming library which Drill uses for the Excel reader.  He has 
contributed numerous fixes and assistance to Drill relating to the Drill's 
Excel reader.  Please join me in congratulating PJ and welcoming him as a 
committer!

Best,
Charles Givre
PMC Chair, Apache Drill 

[DISCUSS] Keynote for Drill meetup

[Jingchuan Hu]

Hi team,

I am thinking that we could do screen recording for our each meetup.
1. We could use Zoom built-in screen recording feature directly, and that
needs permission from James.
2. After the meetup, we could summarize the keynote, edit the spotlight of
the meetup, like, the discussion of new version release, idea sharing and
etc.,
3. And we could upload the keynote and spotlight clips to github wiki,
youtube and bilibili (for users and developers from China).
So that we can fully record our meetup history, and it's convenient for new
users to get known about Drill.
If the community thinks that this is worth doing. I am willing to be
responsible for this procedure.
And please provide more suggestions for this idea.

Best,
Jingchuan

Re: [DISCUSS] Lombok - friend or foe?

[James Turton]

It's a great suggestion and we must in general keep our eyes open for 
suitable tasks for newcomers.  I feel there are also reasons for the 
making this specific case one we do ourselves, however.  If Lombok's 
very presence stops newcomers, because they struggle to get going with 
their dev tools of choice then, for as as long we have it, they cannot 
go directly to working on e.g. a SQL function or a plugin.  They must 
either make their tools compatible or do our unlomboking for us first.


Entirely separately, Vova volunteered in a Slack message to remove 
Lombok based on this email thread.  He knows exactly where it's been 
applied and what we need from the replacement code in those places, so I 
think it would be very quick and error-free for him...



On 2022/01/24 11:24, luoc wrote:

I recommend creating this small task on GitHub Issues or JIRA, adding the 
"newcomer" tag to provide a good chance (to contribute) for newcomers.

Supporting new developers is the best thing for the Drill community.

Thanks.


2022年1月24日 下午5:01，James Turton  写道：

Okay, let's approach it that way around: remove it entirely, and Lombok can 
make a return to plugins *after* they start being built and tested away from 
the main tree, if any plugin authors want it.

P.S. Plugins did indeed not annotate any data objects.  Lombok's use there, in 
what I've seen, has been for the automatic generation of stuff like 
constructors, getters, setters, loggers, toStrings and hashCodes.  That's just 
for interest's sake, not an effort to remotivate Lombok's inclusion.

On 2022/01/24 10:16, Paul Rogers wrote:

A quick check of the source suggests that the Easy Format config builder
(which is a nice addition) does not use Lomboc. Someone coded up (or had
their IDE code up) the setters one-by-one. Makes sense, Lombok isn't for
the builder pattern.

Note that, allowing Lomboc in any part of Drill is the same as allowing it
everywhere. The old CS thing that the only numbers that matter are 0, 1 and
infinity. To do a PR, all tests should pass, which means that the IDE needs
to be able to debug any that have problems. If any plugin uses Lomboc, then
developers have to wrestle with it. (But, what is a plugin doing with data
objects?)

So, perhaps remove it entirely for now. It can be added back for extensions
when those extensions are separate projects. (Though, adding that
dependency on one extension adds it for everyone. Will there be Lomboc
version conflicts? Should we wait for class loader isolation before
allowing it back?)

In general, Drill is so large that it should not take on more dependencies
unless they are a huge win. This is a reason to move the obscure plugins
out of the core: mucking with distributed systems should also require one
to muck with Excel.

- Paul

On Sun, Jan 23, 2022 at 11:59 PM James Turton  wrote:


I'll prepare a PR that unlomboks everything except contrib.  Since we're
talking about contrib splitting off into one or many independent code
bases (c.f. install "Drill 2 and plug-in organisation"), working to make
it conform to coding standards that we're selecting for core Drill
probably won't pay.

On 2022/01/23 01:36, Charles Givre wrote:

I guess the question is do we de-lombok what has already been done?  I

really like the builders for plugin configs, but I'm generally in agreement
that if it is causing problems building, we should ditch it.

Best,
-- C




On Jan 22, 2022, at 5:02 PM, Ted Dunning  wrote:

The Lombok story is better in Intellij, possibly because the Lombok devs
use IntelliJ like the majority of devs. Once I knew to install the

plugin,

things were at least comprehensible.

But the problem is that it isn't obvious. As a newcomer, you don't know
what you don't know and because Lombok's major effect is code that isn't
there, it isn't obvious where to look.

The point about it not helping that much due to Drill's design (good

point,

paul) is apposite, but I think the naive reader issue is even bigger.

Net, as a person who isn't developing anything for Drill just lately, I
don't think it's a good idea at all.



On Sat, Jan 22, 2022 at 6:37 AM luoc  wrote:


Hi all,

I have a story here. In Oct 2021, I upgraded Eclipse to the latest

release

(2021–09) and then found out that the Lombok dependency was added Drill
repository, So I installed Lombok (as a new plugin) from Eclipse
Marketplace as I used to. Finally, restarted the IDE and prepared to

open

the Drill project, but it is crushed cause by the issue #2956 <
https://github.com/projectlombok/lombok/issues/2956>, Lombok was not
available until I looked at a temporary solution..

I use both Eclipse and IDEA, but I use Eclipse more often. I have no
objection to the use of Lombok, but suggest the following three points

:

1. Could we use Lombok only in `drill-contrib` module?

2. Could we agree not to use Lombok in common module?

3. It is best to update the dev documentation to describe this results

if

we continue to use Lombok.

In 

[GitHub] [drill-site] luocooong commented on pull request #24: install-dril-on-dataproc-in-distributed-mode

[GitBox]

luocooong commented on pull request #24:
URL: https://github.com/apache/drill-site/pull/24#issuecomment-1019901261


   @mohamedkashifuddin Thank you for that great contribution.
   @paul-rogers Could we provide any suggestions for the auto-script file?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] Lombok - friend or foe?

[luoc]

I recommend creating this small task on GitHub Issues or JIRA, adding the 
"newcomer" tag to provide a good chance (to contribute) for newcomers.

Supporting new developers is the best thing for the Drill community.

Thanks.

> 2022年1月24日 下午5:01，James Turton  写道：
> 
> Okay, let's approach it that way around: remove it entirely, and Lombok can 
> make a return to plugins *after* they start being built and tested away from 
> the main tree, if any plugin authors want it.
> 
> P.S. Plugins did indeed not annotate any data objects.  Lombok's use there, 
> in what I've seen, has been for the automatic generation of stuff like 
> constructors, getters, setters, loggers, toStrings and hashCodes.  That's 
> just for interest's sake, not an effort to remotivate Lombok's inclusion.
> 
> On 2022/01/24 10:16, Paul Rogers wrote:
>> A quick check of the source suggests that the Easy Format config builder
>> (which is a nice addition) does not use Lomboc. Someone coded up (or had
>> their IDE code up) the setters one-by-one. Makes sense, Lombok isn't for
>> the builder pattern.
>> 
>> Note that, allowing Lomboc in any part of Drill is the same as allowing it
>> everywhere. The old CS thing that the only numbers that matter are 0, 1 and
>> infinity. To do a PR, all tests should pass, which means that the IDE needs
>> to be able to debug any that have problems. If any plugin uses Lomboc, then
>> developers have to wrestle with it. (But, what is a plugin doing with data
>> objects?)
>> 
>> So, perhaps remove it entirely for now. It can be added back for extensions
>> when those extensions are separate projects. (Though, adding that
>> dependency on one extension adds it for everyone. Will there be Lomboc
>> version conflicts? Should we wait for class loader isolation before
>> allowing it back?)
>> 
>> In general, Drill is so large that it should not take on more dependencies
>> unless they are a huge win. This is a reason to move the obscure plugins
>> out of the core: mucking with distributed systems should also require one
>> to muck with Excel.
>> 
>> - Paul
>> 
>> On Sun, Jan 23, 2022 at 11:59 PM James Turton  wrote:
>> 
>>> I'll prepare a PR that unlomboks everything except contrib.  Since we're
>>> talking about contrib splitting off into one or many independent code
>>> bases (c.f. install "Drill 2 and plug-in organisation"), working to make
>>> it conform to coding standards that we're selecting for core Drill
>>> probably won't pay.
>>> 
>>> On 2022/01/23 01:36, Charles Givre wrote:
 I guess the question is do we de-lombok what has already been done?  I
>>> really like the builders for plugin configs, but I'm generally in agreement
>>> that if it is causing problems building, we should ditch it.
 Best,
 -- C
 
 
 
> On Jan 22, 2022, at 5:02 PM, Ted Dunning  wrote:
> 
> The Lombok story is better in Intellij, possibly because the Lombok devs
> use IntelliJ like the majority of devs. Once I knew to install the
>>> plugin,
> things were at least comprehensible.
> 
> But the problem is that it isn't obvious. As a newcomer, you don't know
> what you don't know and because Lombok's major effect is code that isn't
> there, it isn't obvious where to look.
> 
> The point about it not helping that much due to Drill's design (good
>>> point,
> paul) is apposite, but I think the naive reader issue is even bigger.
> 
> Net, as a person who isn't developing anything for Drill just lately, I
> don't think it's a good idea at all.
> 
> 
> 
> On Sat, Jan 22, 2022 at 6:37 AM luoc  wrote:
> 
>> Hi all,
>> 
>> I have a story here. In Oct 2021, I upgraded Eclipse to the latest
>>> release
>> (2021–09) and then found out that the Lombok dependency was added Drill
>> repository, So I installed Lombok (as a new plugin) from Eclipse
>> Marketplace as I used to. Finally, restarted the IDE and prepared to
>>> open
>> the Drill project, but it is crushed cause by the issue #2956 <
>> https://github.com/projectlombok/lombok/issues/2956>, Lombok was not
>> available until I looked at a temporary solution..
>> 
>> I use both Eclipse and IDEA, but I use Eclipse more often. I have no
>> objection to the use of Lombok, but suggest the following three points
>>> :
>> 1. Could we use Lombok only in `drill-contrib` module?
>> 
>> 2. Could we agree not to use Lombok in common module?
>> 
>> 3. It is best to update the dev documentation to describe this results
>>> if
>> we continue to use Lombok.
>> 
>> In fact, I have the same idea as Paul, more about balancing choices.
>> 
>> Thanks.
>> 
>>> 2022年1月22日 下午5:34，Paul Rogers  写道：
>>> 
>>> Hi All,
>>> 
>>> I look at any tool as a cost/benefit tradeoff. If Drill were a typical
>>> business app, with lots of "data objects", then the hassle of Lomboc
>> might
>>> be a net win. 

[GitHub] [drill-site] mohamedkashifuddin opened a new pull request #24: install-dril-on-dataproc-in-distributed-mode

[GitBox]

mohamedkashifuddin opened a new pull request #24:
URL: https://github.com/apache/drill-site/pull/24


   ### This pull request contains the instructions to install drill on gcp 
dataproc
   ---
   1. This is a documentation to install drill on gcp. 
   2. This script installs drill on dataproc  as distributed mode with the help 
of automation scripts.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@drill.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] Lombok - friend or foe?

[James Turton]

Okay, let's approach it that way around: remove it entirely, and Lombok 
can make a return to plugins *after* they start being built and tested 
away from the main tree, if any plugin authors want it.


P.S. Plugins did indeed not annotate any data objects.  Lombok's use 
there, in what I've seen, has been for the automatic generation of stuff 
like constructors, getters, setters, loggers, toStrings and hashCodes.  
That's just for interest's sake, not an effort to remotivate Lombok's 
inclusion.


On 2022/01/24 10:16, Paul Rogers wrote:

A quick check of the source suggests that the Easy Format config builder
(which is a nice addition) does not use Lomboc. Someone coded up (or had
their IDE code up) the setters one-by-one. Makes sense, Lombok isn't for
the builder pattern.

Note that, allowing Lomboc in any part of Drill is the same as allowing it
everywhere. The old CS thing that the only numbers that matter are 0, 1 and
infinity. To do a PR, all tests should pass, which means that the IDE needs
to be able to debug any that have problems. If any plugin uses Lomboc, then
developers have to wrestle with it. (But, what is a plugin doing with data
objects?)

So, perhaps remove it entirely for now. It can be added back for extensions
when those extensions are separate projects. (Though, adding that
dependency on one extension adds it for everyone. Will there be Lomboc
version conflicts? Should we wait for class loader isolation before
allowing it back?)

In general, Drill is so large that it should not take on more dependencies
unless they are a huge win. This is a reason to move the obscure plugins
out of the core: mucking with distributed systems should also require one
to muck with Excel.

- Paul

On Sun, Jan 23, 2022 at 11:59 PM James Turton  wrote:


I'll prepare a PR that unlomboks everything except contrib.  Since we're
talking about contrib splitting off into one or many independent code
bases (c.f. install "Drill 2 and plug-in organisation"), working to make
it conform to coding standards that we're selecting for core Drill
probably won't pay.

On 2022/01/23 01:36, Charles Givre wrote:

I guess the question is do we de-lombok what has already been done?  I

really like the builders for plugin configs, but I'm generally in agreement
that if it is causing problems building, we should ditch it.

Best,
-- C




On Jan 22, 2022, at 5:02 PM, Ted Dunning  wrote:

The Lombok story is better in Intellij, possibly because the Lombok devs
use IntelliJ like the majority of devs. Once I knew to install the

plugin,

things were at least comprehensible.

But the problem is that it isn't obvious. As a newcomer, you don't know
what you don't know and because Lombok's major effect is code that isn't
there, it isn't obvious where to look.

The point about it not helping that much due to Drill's design (good

point,

paul) is apposite, but I think the naive reader issue is even bigger.

Net, as a person who isn't developing anything for Drill just lately, I
don't think it's a good idea at all.



On Sat, Jan 22, 2022 at 6:37 AM luoc  wrote:


Hi all,

I have a story here. In Oct 2021, I upgraded Eclipse to the latest

release

(2021–09) and then found out that the Lombok dependency was added Drill
repository, So I installed Lombok (as a new plugin) from Eclipse
Marketplace as I used to. Finally, restarted the IDE and prepared to

open

the Drill project, but it is crushed cause by the issue #2956 <
https://github.com/projectlombok/lombok/issues/2956>, Lombok was not
available until I looked at a temporary solution..

I use both Eclipse and IDEA, but I use Eclipse more often. I have no
objection to the use of Lombok, but suggest the following three points

:

1. Could we use Lombok only in `drill-contrib` module?

2. Could we agree not to use Lombok in common module?

3. It is best to update the dev documentation to describe this results

if

we continue to use Lombok.

In fact, I have the same idea as Paul, more about balancing choices.

Thanks.


2022年1月22日 下午5:34，Paul Rogers  写道：

Hi All,

I look at any tool as a cost/benefit tradeoff. If Drill were a typical
business app, with lots of "data objects", then the hassle of Lomboc

might

be a net win. However, the nature of Drill is that we have very few

data

objects. We have lots of Protobuf objects, or Jackson-serialized

objects,

but not too many data objects of the kind used with object-relational
mappers.

On the other hand, I had to spend an hour or so trying to figure out

why

things would not build in Eclipse. Then, more time to figure out how

to

install the half-finished Lomboc plugin for Eclipse and various other
fiddling.

So, I'd guess, on balance, Lombok has cost, and will continue to cost,

more

time than it saved avoiding a few getter/setter methods. And, I agree

with

Ted, Eclipse (and, I assume IntelliJ), is pretty quick at generating

those

methods.

Since Lomboc has a cost, and is not a huge win, KISS suggests we avoid
adding extra 

Re: [DISCUSS] Lombok - friend or foe?

[Paul Rogers]

A quick check of the source suggests that the Easy Format config builder
(which is a nice addition) does not use Lomboc. Someone coded up (or had
their IDE code up) the setters one-by-one. Makes sense, Lombok isn't for
the builder pattern.

Note that, allowing Lomboc in any part of Drill is the same as allowing it
everywhere. The old CS thing that the only numbers that matter are 0, 1 and
infinity. To do a PR, all tests should pass, which means that the IDE needs
to be able to debug any that have problems. If any plugin uses Lomboc, then
developers have to wrestle with it. (But, what is a plugin doing with data
objects?)

So, perhaps remove it entirely for now. It can be added back for extensions
when those extensions are separate projects. (Though, adding that
dependency on one extension adds it for everyone. Will there be Lomboc
version conflicts? Should we wait for class loader isolation before
allowing it back?)

In general, Drill is so large that it should not take on more dependencies
unless they are a huge win. This is a reason to move the obscure plugins
out of the core: mucking with distributed systems should also require one
to muck with Excel.

- Paul

On Sun, Jan 23, 2022 at 11:59 PM James Turton  wrote:

> I'll prepare a PR that unlomboks everything except contrib.  Since we're
> talking about contrib splitting off into one or many independent code
> bases (c.f. install "Drill 2 and plug-in organisation"), working to make
> it conform to coding standards that we're selecting for core Drill
> probably won't pay.
>
> On 2022/01/23 01:36, Charles Givre wrote:
> > I guess the question is do we de-lombok what has already been done?  I
> really like the builders for plugin configs, but I'm generally in agreement
> that if it is causing problems building, we should ditch it.
> > Best,
> > -- C
> >
> >
> >
> >> On Jan 22, 2022, at 5:02 PM, Ted Dunning  wrote:
> >>
> >> The Lombok story is better in Intellij, possibly because the Lombok devs
> >> use IntelliJ like the majority of devs. Once I knew to install the
> plugin,
> >> things were at least comprehensible.
> >>
> >> But the problem is that it isn't obvious. As a newcomer, you don't know
> >> what you don't know and because Lombok's major effect is code that isn't
> >> there, it isn't obvious where to look.
> >>
> >> The point about it not helping that much due to Drill's design (good
> point,
> >> paul) is apposite, but I think the naive reader issue is even bigger.
> >>
> >> Net, as a person who isn't developing anything for Drill just lately, I
> >> don't think it's a good idea at all.
> >>
> >>
> >>
> >> On Sat, Jan 22, 2022 at 6:37 AM luoc  wrote:
> >>
> >>> Hi all,
> >>>
> >>> I have a story here. In Oct 2021, I upgraded Eclipse to the latest
> release
> >>> (2021–09) and then found out that the Lombok dependency was added Drill
> >>> repository, So I installed Lombok (as a new plugin) from Eclipse
> >>> Marketplace as I used to. Finally, restarted the IDE and prepared to
> open
> >>> the Drill project, but it is crushed cause by the issue #2956 <
> >>> https://github.com/projectlombok/lombok/issues/2956>, Lombok was not
> >>> available until I looked at a temporary solution..
> >>>
> >>> I use both Eclipse and IDEA, but I use Eclipse more often. I have no
> >>> objection to the use of Lombok, but suggest the following three points
> :
> >>>
> >>> 1. Could we use Lombok only in `drill-contrib` module?
> >>>
> >>> 2. Could we agree not to use Lombok in common module?
> >>>
> >>> 3. It is best to update the dev documentation to describe this results
> if
> >>> we continue to use Lombok.
> >>>
> >>> In fact, I have the same idea as Paul, more about balancing choices.
> >>>
> >>> Thanks.
> >>>
>  2022年1月22日 下午5:34，Paul Rogers  写道：
> 
>  Hi All,
> 
>  I look at any tool as a cost/benefit tradeoff. If Drill were a typical
>  business app, with lots of "data objects", then the hassle of Lomboc
> >>> might
>  be a net win. However, the nature of Drill is that we have very few
> data
>  objects. We have lots of Protobuf objects, or Jackson-serialized
> objects,
>  but not too many data objects of the kind used with object-relational
>  mappers.
> 
>  On the other hand, I had to spend an hour or so trying to figure out
> why
>  things would not build in Eclipse. Then, more time to figure out how
> to
>  install the half-finished Lomboc plugin for Eclipse and various other
>  fiddling.
> 
>  So, I'd guess, on balance, Lombok has cost, and will continue to cost,
> >>> more
>  time than it saved avoiding a few getter/setter methods. And, I agree
> >>> with
>  Ted, Eclipse (and, I assume IntelliJ), is pretty quick at generating
> >>> those
>  methods.
> 
>  Since Lomboc has a cost, and is not a huge win, KISS suggests we avoid
>  adding extra dependencies unnecessarily.
> 
>  That's my 2 cents...
> 
>  - Paul
> 
> 
> 
>  On Fri,