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 <[email protected]> 写道： > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 写道： >>>>>>> >>>>>>> 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, Jan 21, 2022 at 8:51 AM Ted Dunning <[email protected]> >>>>>> wrote: >>>>>>>> A couple of years ago, I had a dev introduce Lombok into some code >>>>>> without >>>>>>>> me knowing. That let me be a classic naive user. >>>>>>>> >>>>>>>> The result was total confusion on my part. Sooo much code was being >>>>>>>> automagically generated that I couldn't figure out the code and >>> spent a >>>>>> lot >>>>>>>> of time chasing my tail and very little time looking at the crux of >>> the >>>>>>>> code. >>>>>>>> >>>>>>>> My own personal preference is either >>>>>>>> >>>>>>>> - use a language like Julia if you want magic. It's fantastic and >>> all to >>>>>>>> have amazing stuff and coders expect to see it. >>>>>>>> >>>>>>>> - use an IDE to generate the boiler plate and put it into its own >>> little >>>>>>>> annex in the code with the interesting bits near the top of classes. >>>>>> That >>>>>>>> lets debuggers and IDEs that don't understand Lombok to function >>> without >>>>>>>> impairing readability much. Concurrent with that, use discipline to >>> not >>>>>> do >>>>>>>> strange things like changing the expected meaning of the boilerplate. >>>>>>>> >>>>>>>> That's my preference, but I wouldn't want to push that preference >>> very >>>>>>>> hard. My own prioritization is on readability of the code by >>> outsiders. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jan 21, 2022 at 2:25 AM James Turton <[email protected]> >>> wrote: >>>>>>>>> Hi again Devs >>>>>>>>> >>>>>>>>> This one is simple to describe. Lombok entered the Drill code base >>>>>> this >>>>>>>>> year, but not everyone feels that Lombok is appropriate for every >>> code >>>>>>>>> base. To my, fairly limited, understanding the advantage of Lombok >>> is >>>>>>>>> that boilerplate code is reduced while the disadvantage is the >>>>>>>>> deployment of code generation magic that can have untoward effects >>> on >>>>>>>>> build-time tools and IDEs. >>>>>>>>> >>>>>>>>> So here is a chance to opine on Lombok if you'd like to. My own >>>>>> opinion >>>>>>>>> is very near neutral and goes something like "It burned me a bit >>> once, >>>>>>>>> but hasn't since, and less boilerplate is nice. I guess it can stay >>>>>>>>> <shrug>. I hope I don't regret this one day." >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> James >>>>>>>>> >>>
