>>
> > >> On Wed, 25 Jan 2023 at 13:05, Miklosovic, Stefan
> > >> wrote:
> > >> >
> > >> > Thank you Maxim for doing this.
> > >> >
> > >> > It is nice to see this effort materialized in a PR.
> >
like Accord will be
in trunk on Monday and we release Tuesday ...
From: Maxim Muzafarov
Sent: Monday, July 31, 2023 23:05
To: dev@cassandra.apache.org
Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
NetApp Security WARNING: Th
bringing this topic up. I'll prepare the PR shortly with
> >> > > option 4, so everyone can take a look at the amount of changes. This
> >> > > does not force us to go exactly this path, but it may shed light on
> >> > > changes in general.
> >> > >
>
ple would like to include in 5.0. This can go in anytime,
>> > basically.
>> >
>> > Are people on the same page?
>> >
>> > Regards
>> >
>> >
>> > From: Maxim Muzafarov
>> &g
t;
> > > ```
> > > java.*
> > > javax.*
> > > [blank line]
> > > com.*
> > > net.*
> > > org.*
> > > [blank line]
> > > org.apache.cassandra.*
> > > [blank line]
> > > all other imports
> > > [bla
*
> > [blank line]
> > all other imports
> > [blank line]
> > static all other imports
> > ```
> >
> >
> >
> > On Mon, 16 Jan 2023 at 12:39, Miklosovic, Stefan
> > wrote:
> > >
> > > Based on the voting we should go with opti
in 5.0. This can go in anytime,
> basically.
>
> Are people on the same page?
>
> Regards
>
>
> From: Maxim Muzafarov
> Sent: Monday, January 23, 2023 19:46
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSSION] Cassandra&#x
time until the end of this week (Friday 12:00 UTC).
> >
> > Regards
> >
> > ____
> > From: Maxim Muzafarov
> > Sent: Tuesday, January 3, 2023 14:31
> > To: dev@cassandra.apache.org
> > Subject: Re: [DISCUSSION] Cass
so I guess folks are all happy
> > with that or this just went unnoticed?
> >
> > Let's give it time until the end of this week (Friday 12:00 UTC).
> >
> > Regards
> >
> >
> > From: Maxim Muzafarov
> > Sent:
3, 2023 14:31
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content
Maxim Muzafarov
Sent: Tuesday, January 3, 2023 14:31
To: dev@cassandra.apache.org
Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the conte
Folks,
Let me update the voting status and put together everything we have so
far. We definitely need more votes to have a solid foundation for this
change, so I encourage everyone to consider the options above and
share them in this thread.
Total for each applicable option:
4-th option -- 4 vo
>
>
> 3. Total 5 groups, 2968 files to change
>
> ```
> org.apache.cassandra.*
> [blank line]
> java.*
> [blank line]
> javax.*
> [blank line]
> all other imports
> [blank line]
> static all other imports
> ```
>
3, then 5.
There's lots under com.*, net.*, org.* that is essentially the same as "a
Im good with 3 and 4.
> On Dec 22, 2022, at 10:41 AM, Derek Chen-Becker wrote:
>
> I vote for #4. I've always used the convention of having stdlib stuff
> first, external stuff second, and same-project imports last. I guess
> increasing order of specificity?
>
> Happy Holidays!
>
> Derek
>
>
I vote for #4. I've always used the convention of having stdlib stuff
first, external stuff second, and same-project imports last. I guess
increasing order of specificity?
Happy Holidays!
Derek
On Thu, Dec 22, 2022 at 7:52 AM Maxim Muzafarov wrote:
>
> Hello everyone, have a great vacation and
ect: Re: [DISCUSSION] Cassandra's code style and source code analysis
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
Hello everyone, have a great vacation and happy holidays to all!
I like 3 or 4.
We need to be sure we have a way of deactivating the check with code comments
tho, as Java 8 has some bug with import order that can rarely break
compilation, so we need to have some mechanism for permitting a different
import order.
Did we decide any changes to star imports?
Hello everyone, have a great vacation and happy holidays to all!
I've completed a small research about how the classe's import order
rule are spread in the Apache projects. Some of the projects don't
have any restrictions over the imports even if they are using the
checkstyle configuration. The o
>
> Another angle I forgot to mention is that this is quite a big patch and
> there are quite big pieces of work coming, being it CEP-15, for example. So
> I am trying to figure out if we are ok to just merge this work first and
> devs doing CEP-15 will need to rework their imports or we merge this
CASSANDRA-17925
From: Maxim Muzafarov
Sent: Monday, December 12, 2022 17:13
To: dev@cassandra.apache.org
Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
NetApp Security WARNING: This is an external email. Do not click links or open
attachments
t;>>> > However, responding to Stefan, I’m pretty -1 migrating from ant to
> >>>> > another build system without really good reason. Migration has a real
> >>>> > cost to productivity for all existing contributors, and the phantom of
> >>>
?
From: Maxim Muzafarov
Sent: Wednesday, December 7, 2022 18:29
To: dev@cassandra.apache.org
Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
NetApp Security WARNING: This is an external email. Do not click links or open
attach
n <
> stefan.mikloso...@netapp.com> wrote:
> >>>>
> >>>> I agree with what you wrote. How I understand it is that migrating to
> Maven/Gradle makes the project more "attractive" for newcomers. If a
> project is built on "
ol Ant", it might be a little bit
>>>> off-putting and questionable if we are "stuck in the past on build systems
>>>> and not progressing".
>>>>
>>>> So in that sense I agree this is more "marketing" rather than
past on build systems
>>> and not progressing".
>>>
>>> So in that sense I agree this is more "marketing" rather than
>>> technological question but on the other hand, does not Maven/Gradle allow
>>> us to modularize the project better? Ma
because build system makes it impossible or at least
>> quite inconvenient to do so. Do you really think there are not any
>> significant benefits to switch even if it "just works" now?
>>
>>
>> From: Benedict
>> Sent: Friday
adle
project and nothing else so people could gradually add to that. And maybe once
we will flip the switch, who knows.
From: Benedict
Sent: Wednesday, November 30, 2022 10:29
To: dev@cassandra.apache.org
Subject: Re: [DISCUSSION] Cassandra's code st
;
>> Why do you consider a migration inevitable?
>>
>>
>>
>> > On 25 Nov 2022, at 09:58, Miklosovic, Stefan
>> > wrote:
>> >
>> > Interesting take on Ant / no-Ant, Benedict. I am very curious how this
>> > unfolds. My long-term perception is that changing it
; quite inconvenient to do so. Do you really think there are not any
> significant benefits to switch even if it "just works" now?
>
> ________________
> From: Benedict
> Sent: Friday, November 25, 2022 11:07
> To: dev@cassandra.apache.org
> Subject: R
So much awesome here. Big +1 to having checkstyle be the source of truth.
On 2022/11/24 17:10:28 Maxim Muzafarov wrote:
> Hello everyone,
>
>
> First of all, thank you all for this awesome project which I have
> often been inspired by. My name is Maxim Muzafarov I'm a Committer and
> PMC of Ap
te:
Interesting take on Ant / no-Ant, Benedict. I am very curious
how this unfolds. My long-term perception is that changing it to
something else is more or less inevitable but if there is a
broader consensus to not do that well.
From: Benedic
king it, and therefore its relative payoff
>>>> versus other things that could be undertaken by the folk with the relevant
>>>> expertise to do it.
>>>>
>>>> I’ve also been around long enough to see enough efforts to broaden
>>>> contrib
he folk with the relevant
>>>> expertise to do it.
>>>>
>>>> I’ve also been around long enough to see enough efforts to broaden
>>>> contributions fail to have an impact, that basing costly decisions on this
>>>> kind of reasoning d
Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
>>>>
>>>> NetApp Security WARNING: This is an external email. Do not click links or
>>>> open attachments unless you recognize the sender and know the content is
>>>> s
.
> >>
> >> So in that sense I agree this is more "marketing" rather than
> >> technological question but on the other hand, does not Maven/Gradle allow
> >> us to modularize the project better? Maybe we would like to modularize but
> >> nobod
good argument articulated for the migration, besides
> >> general hand waving that ant is old, and people like newer build systems.
> >> Ant is working fine, so there isn’t a strong technical reason to replace
> >> it, and there are good organisational reasons not to.
> >
gt; that because build system makes it impossible or at least quite inconvenient
>> to do so. Do you really think there are not any significant benefits to
>> switch even if it "just works" now?
>>
>>
>> From: Ben
nk there are not any significant benefits to
> switch even if it "just works" now?
>
>
> From: Benedict
> Sent: Friday, November 25, 2022 11:07
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
>
> NetAp
___
> From: Benedict
> Sent: Friday, November 25, 2022 10:52
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attac
or less inevitable but if there is a broader consensus to not do that
>> well.
>>
>>
>> From: Benedict
>> Sent: Friday, November 25, 2022 10:52
>> To: dev@cassandra.apache.org
>> Subject: Re: [DISCUSSION] Cassandra's code style an
sus to not do that
> well.
>
>
> From: Benedict
> Sent: Friday, November 25, 2022 10:52
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
>
> NetApp Security WARNING
: Friday, November 25, 2022 10:52
To: dev@cassandra.apache.org
Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
oned only in case they do not collide with any build system at all.
>
> (1) https://issues.apache.org/jira/browse/CASSANDRA-17964
>
> Stefan
>
>
> From: Claude Warren, Jr via dev
> Sent: Friday, November 25, 2022 10:16
> To
/CASSANDRA-17964
Stefan
From: Claude Warren, Jr via dev
Sent: Friday, November 25, 2022 10:16
To: dev@cassandra.apache.org
Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis
NetApp Security WARNING: This is an external email. Do not
+1 for the concept as a whole. I am certain I could find nits to pick if I
looked deeply.
@mck -- I did have a problem with Cassandra + Eclipse + Java11
(Classpath). I gave up and am spending time trying to learn IntelliJ. I
also mentioned it in one of the discussion areas.
Claude
On Thu, Nov
> == 1. Make the checkstyle config a single point of truth for the
> source code style. ==
-1, the single point of truth is the wiki - everything else follows this. The
code style is a community consensus, and as previously discussed the last time
it came up, mostly not strict. If we intend to i
Thank you for a solid write up Maxim. And welcome to Cassandra, it's
very positive to see you here.
I whole-heartedly agree with nearly everything you write. Some input
and questions inline.
>
> As you may know, the infrastructure team has disabled public sign-up
> to ASF JIRA (the GitHub issue
47 matches
Mail list logo
