[jira] [Updated] (CASSANDRA-18186) WEBSITE - Add "registered" symbol (R) to first occurrence of "Cassandra" on homepage + footer
[
https://issues.apache.org/jira/browse/CASSANDRA-18186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18186:
--
Change Category: Semantic
Complexity: Normal
Component/s: Documentation/Website
Fix Version/s: NA
Reviewers: Michael Semb Wever
Status: Open (was: Triage Needed)
> WEBSITE - Add "registered" symbol (R) to first occurrence of "Cassandra" on
> homepage + footer
> -
>
> Key: CASSANDRA-18186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18186
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: NA
>
>
> In response to the review by Mark Thomas/ASF Brand Management and in-line
> with the ASF [Apache Website Project Branding
> Policy|https://www.apache.org/foundation/marks/pmcs] specifically:
> {quote}At the top of each project or product homepage, and on the top banner
> of each page where the project name appears, you should include the
> appropriate ™ or ® symbol next to the first main occurrence of the "Apache
> Foo" project name, both in header/title text and at the name's first
> appearance in running text. This highlights our trademark claim and
> emphasizes its importance to us.{quote}
> we need to add the "registered" symbol (®) to:
> * the first occurrence of "Cassandra" on the homepage, and
> * the main occurrence of "Cassandra" in the footer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18186) WEBSITE - Add "registered" symbol (R) to first occurrence of "Cassandra" on homepage + footer
Erick Ramirez created CASSANDRA-18186: - Summary: WEBSITE - Add "registered" symbol (R) to first occurrence of "Cassandra" on homepage + footer Key: CASSANDRA-18186 URL: https://issues.apache.org/jira/browse/CASSANDRA-18186 Project: Cassandra Issue Type: Task Reporter: Erick Ramirez Assignee: Erick Ramirez In response to the review by Mark Thomas/ASF Brand Management and in-line with the ASF [Apache Website Project Branding Policy|https://www.apache.org/foundation/marks/pmcs] specifically: > At the top of each project or product homepage, and on the top banner of each > page where the project name appears, you should include the appropriate ™ or > ® symbol next to the first main occurrence of the "Apache Foo" project name, > both in header/title text and at the name's first appearance in running text. > This highlights our trademark claim and emphasizes its importance to us. we need to add the "registered" symbol (®) to: * the first occurrence of "Cassandra" on the homepage, and * the main occurrence of "Cassandra" in the footer. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18186) WEBSITE - Add "registered" symbol (R) to first occurrence of "Cassandra" on homepage + footer
[
https://issues.apache.org/jira/browse/CASSANDRA-18186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-18186:
--
Description:
In response to the review by Mark Thomas/ASF Brand Management and in-line with
the ASF [Apache Website Project Branding
Policy|https://www.apache.org/foundation/marks/pmcs] specifically:
{quote}At the top of each project or product homepage, and on the top banner of
each page where the project name appears, you should include the appropriate ™
or ® symbol next to the first main occurrence of the "Apache Foo" project name,
both in header/title text and at the name's first appearance in running text.
This highlights our trademark claim and emphasizes its importance to us.{quote}
we need to add the "registered" symbol (®) to:
* the first occurrence of "Cassandra" on the homepage, and
* the main occurrence of "Cassandra" in the footer.
was:
In response to the review by Mark Thomas/ASF Brand Management and in-line with
the ASF [Apache Website Project Branding
Policy|https://www.apache.org/foundation/marks/pmcs] specifically:
> At the top of each project or product homepage, and on the top banner of each
> page where the project name appears, you should include the appropriate ™ or
> ® symbol next to the first main occurrence of the "Apache Foo" project name,
> both in header/title text and at the name's first appearance in running text.
> This highlights our trademark claim and emphasizes its importance to us.
we need to add the "registered" symbol (®) to:
* the first occurrence of "Cassandra" on the homepage, and
* the main occurrence of "Cassandra" in the footer.
> WEBSITE - Add "registered" symbol (R) to first occurrence of "Cassandra" on
> homepage + footer
> -
>
> Key: CASSANDRA-18186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18186
> Project: Cassandra
> Issue Type: Task
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
>
> In response to the review by Mark Thomas/ASF Brand Management and in-line
> with the ASF [Apache Website Project Branding
> Policy|https://www.apache.org/foundation/marks/pmcs] specifically:
> {quote}At the top of each project or product homepage, and on the top banner
> of each page where the project name appears, you should include the
> appropriate ™ or ® symbol next to the first main occurrence of the "Apache
> Foo" project name, both in header/title text and at the name's first
> appearance in running text. This highlights our trademark claim and
> emphasizes its importance to us.{quote}
> we need to add the "registered" symbol (®) to:
> * the first occurrence of "Cassandra" on the homepage, and
> * the main occurrence of "Cassandra" in the footer.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18051) Optimize test_network_topology_strategy and test_network_topology_strategy_each_quorum for large containers in CircleCI
[
https://issues.apache.org/jira/browse/CASSANDRA-18051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679684#comment-17679684
]
Berenguer Blasi commented on CASSANDRA-18051:
-
Would it make sense to create a new circle job 'dtest-that-need-high-resources'
and put those 2 tests in with increased resources only there? If that were a
waste of resource we make that one guarded by approval as jenkins should catch
any glaring errors.
> Optimize test_network_topology_strategy and
> test_network_topology_strategy_each_quorum for large containers in CircleCI
> ---
>
> Key: CASSANDRA-18051
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18051
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> As pointed in CASSANDRA-18001, there are two Python Large DTests that fail
> because of not enough resources with large containers. [~adelapena] looked
> into them and suggested that the tests themselves can be optimized for
> running on Large containers instead of using XLarge containers for only two
> tests from the whole suite.
> {quote}As for the two tests starting nine nodes each,
> {{test_network_topology_strategy}} and
> {{{}test_network_topology_strategy_each_quorum{}}}, I think they were added
> by CASSANDRA-10584 to test multi-DC consistency levels. I wonder if they
> actually need to start 3 data centers with 3 nodes each. Would two data
> centers with 3 nodes be enough to test multi-DC consistency levels with
> multiple data centers? 6 nodes should be doable on Circle with the current
> resources.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18150) Prefer snakeyaml's SafeConstructor over Constructor
[ https://issues.apache.org/jira/browse/CASSANDRA-18150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679683#comment-17679683 ] Berenguer Blasi commented on CASSANDRA-18150: - [~brandon.williams] I tried googling 'could not determine a constructor for the tag'. Is this the error you're referring to? Be it the case the search brought up some useful info it might be worth pulling the thread. Sthg about scalars, free-style objects, providing yourself some code to handle those... > Prefer snakeyaml's SafeConstructor over Constructor > --- > > Key: CASSANDRA-18150 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18150 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > CVE-2022-1471 allows RCE through the Constructor class. While this isn't a > concern since yaml is only used for configuration, it is simple enough to > switch to SafeConstructor and harden the server a little more. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17507) IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679680#comment-17679680
]
Berenguer Blasi commented on CASSANDRA-17507:
-
Dropped a couple nits. Feel free to ignore an commit at your discretion
> IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling
> upgrade
> ---
>
> Key: CASSANDRA-17507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17507
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Thomas Steinmaurer
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In a 6 node 3.11.12 test cluster - freshly set up, thus no legacy SSTables
> etc. - with ~ 1TB SSTables on disk per node, I have been running a rolling
> upgrade to 4.0.3. On upgraded 4.0.3 nodes I then have seen the following
> exception regularly, which disappeared once all 6 nodes have been on 4.0.3.
> Is this known? Can this be ignored? As said, just a test drive, but not sure
> if we want to have that in production, especially with a larger number of
> nodes, where it could take some time, until all are upgraded. Thanks!
> {code}
> ERROR [Native-Transport-Requests-8] 2022-03-30 11:30:24,057
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.IllegalArgumentException: newLimit > capacity: (290 > 15)
> at java.base/java.nio.Buffer.createLimitException(Buffer.java:372)
> at java.base/java.nio.Buffer.limit(Buffer.java:346)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1107)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:262)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:107)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:39)
> at
> org.apache.cassandra.db.marshal.ValueAccessor.sliceWithShortLength(ValueAccessor.java:225)
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:222)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.decodeClustering(PagingState.java:434)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:388)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:88)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:69)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:352)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:400)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:244)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:723)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:701)
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:159)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:86)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:106)
> at
> org.apache.cassandra.transport.Dispatcher.lambda$dispatch$0(Dispatcher.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail:
[jira] [Updated] (CASSANDRA-17507) IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-17507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17507:
Status: Changes Suggested (was: Ready to Commit)
> IllegalArgumentException in query code path during 3.11.12 => 4.0.3 rolling
> upgrade
> ---
>
> Key: CASSANDRA-17507
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17507
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
>Reporter: Thomas Steinmaurer
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In a 6 node 3.11.12 test cluster - freshly set up, thus no legacy SSTables
> etc. - with ~ 1TB SSTables on disk per node, I have been running a rolling
> upgrade to 4.0.3. On upgraded 4.0.3 nodes I then have seen the following
> exception regularly, which disappeared once all 6 nodes have been on 4.0.3.
> Is this known? Can this be ignored? As said, just a test drive, but not sure
> if we want to have that in production, especially with a larger number of
> nodes, where it could take some time, until all are upgraded. Thanks!
> {code}
> ERROR [Native-Transport-Requests-8] 2022-03-30 11:30:24,057
> ErrorMessage.java:457 - Unexpected exception during request
> java.lang.IllegalArgumentException: newLimit > capacity: (290 > 15)
> at java.base/java.nio.Buffer.createLimitException(Buffer.java:372)
> at java.base/java.nio.Buffer.limit(Buffer.java:346)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:1107)
> at java.base/java.nio.ByteBuffer.limit(ByteBuffer.java:262)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:107)
> at
> org.apache.cassandra.db.marshal.ByteBufferAccessor.slice(ByteBufferAccessor.java:39)
> at
> org.apache.cassandra.db.marshal.ValueAccessor.sliceWithShortLength(ValueAccessor.java:225)
> at
> org.apache.cassandra.db.marshal.CompositeType.splitName(CompositeType.java:222)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.decodeClustering(PagingState.java:434)
> at
> org.apache.cassandra.service.pager.PagingState$RowMark.clustering(PagingState.java:388)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:88)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.nextPageReadQuery(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.service.pager.AbstractQueryPager.fetchPage(AbstractQueryPager.java:69)
> at
> org.apache.cassandra.service.pager.SinglePartitionPager.fetchPage(SinglePartitionPager.java:32)
> at
> org.apache.cassandra.cql3.statements.SelectStatement$Pager$NormalPager.fetchPage(SelectStatement.java:352)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:400)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:250)
> at
> org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:88)
> at
> org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:244)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:723)
> at
> org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:701)
> at
> org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:159)
> at
> org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:86)
> at
> org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:106)
> at
> org.apache.cassandra.transport.Dispatcher.lambda$dispatch$0(Dispatcher.java:70)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:165)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:829)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18181) Fix tests post JDK-8210522
[
https://issues.apache.org/jira/browse/CASSANDRA-18181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679650#comment-17679650
]
Ekaterina Dimitrova commented on CASSANDRA-18181:
-
Interesting, I still see issues related to the Python support tickets in
Jenkins, but if I run DTests in CircleCI with the same branches as Jenkins -
they finished
[fine|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2187/workflows/0b2d1d8b-c2c2-48da-9345-d25c01f39e5a]
I will investigate further tomorrow.
> Fix tests post JDK-8210522
> --
>
> Key: CASSANDRA-18181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18181
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
>
> From JDK-8210522:
> {code:java}
> Core reflection has a filtering mechanism to hide security and integrity
> sensitive fields and methods from Class getXXXField(s) and getXXXMethod(s).
> The filtering mechanism has been used for several releases to hide security
> sensitive fields such as System.security and Class.classLoader.
> This CSR proposes to extend the filters to hide fields from a number of
> highly security sensitive classes in java.lang.reflect and java.lang.invoke.
> {code}
> We are using at a few places in our tests
> {code:java}
> Field.class.getDeclaredField("modifiers");{code}
> This breaks as expected when tests are run with JDK17, example:
>
> {code:java}
> java.lang.RuntimeException: java.lang.NoSuchFieldException: modifiers
> at
> org.apache.cassandra.transport.MessagePayloadTest.makeCqlQueryHandlerAccessible(MessagePayloadTest.java:79)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at
> org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:221)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: java.lang.NoSuchFieldException: modifiers at
> java.base/java.lang.Class.getDeclaredField(Class.java:2610)
> at
> org.apache.cassandra.transport.MessagePayloadTest.makeCqlQueryHandlerAccessible(MessagePayloadTest.java:70)
>
> ... 15 more{code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18179) Update current trunk build.xml and conf scripts for JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679647#comment-17679647
]
Ekaterina Dimitrova edited comment on CASSANDRA-18179 at 1/22/23 9:27 PM:
--
{quote}The 17869 patch changes ci-cassandra.a.o to test 11+17 on trunk, so it
needs to wait til 17 tests pass.
{quote}
Yeah, I meant it with the assumption we add a toggle and change things
incrementally as we were discussing on the ticket whether we want that or not.
(to be discussed and decided) In the current state directly switching to 11+17,
indeed, this won't work.
{quote}Quick work around is to add a mention of CASSANDRA_USE_JDK11 in a
comment in this ticket's patch.
{quote}
That should probably work (let's test) if we really want to have this committed
now despite we are not being able to still compile and run CI (even with still
broken tests) until CASSANDRA-17281 lands. It seems that will unblock
CASSANDRA-18133 but not JDK17 broader testing (people still need to at least
comment out the scripted UDFs related classes in their branches)
was (Author: e.dimitrova):
{quote}The 17869 patch changes ci-cassandra.a.o to test 11+17 on trunk, so it
needs to wait til 17 tests pass.
{quote}
Yeah, I meant it with the assumption we add a toggle and change things
incrementally as we were discussing on the ticket whether we want that or not.
(to be discussed and decided) In the current state directly switching to 11+17,
indeed, this won't work.
{quote}Quick work around is to add a mention of CASSANDRA_USE_JDK11 in a
comment in this ticket's patch.
{quote}
That should probably work (let's test) if we really want to have this committed
now despite we are not being able to still compile and run CI (even with still
broken tests) until CASSANDRA-17281 lands. It seems that will unblock
CASSANDRA-18133 but not JDK17 broader testing (people still need to at least
comment out the scripted UDF related classes in their branches)
> Update current trunk build.xml and conf scripts for JDK17
> -
>
> Key: CASSANDRA-18179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18179
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.x
>
>
> To support JDK17 we need to make changes to build.xml and our scripts. There
> is a preliminary patch which makes a switch from JDK8+JDK11 to JDK11+JDK17
> but it will need a change considering CASSANDRA-18133
> CC [~mck]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18089) The source code must obey the avoid star import checkstyle rule
[ https://issues.apache.org/jira/browse/CASSANDRA-18089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679648#comment-17679648 ] Ekaterina Dimitrova commented on CASSANDRA-18089: - Thanks for confirming, based on that I changed it to duplicate to prevent future confusion. Thanks again for all your work :) > The source code must obey the avoid star import checkstyle rule > --- > > Key: CASSANDRA-18089 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18089 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Cassandra has the code style rules regarding the classes import order: > [https://cassandra.apache.org/_/development/code_style.html] > Importing all classes from a package or static members from a class leads to > tight coupling between packages or classes and might lead to problems when a > new library version introduces name clashes. The advantage of explicitly > listing all imports from a package is that you can tell at a glance which > class you meant to use, which does reading and refactoring the source code > that much easier. > The checkstyle that is already used for checking the source code has a such > check and this check may be added to the config both for the production and > test source code: > https://checkstyle.sourceforge.io/config_imports.html#AvoidStaticImport > Besides adding a new checkstyle rule it may be more convenient for those > community members that are working with the code to reflect the same rule in > the IDE's inspection profiles (if it's possible), thus using the 'optimize > imports' will produce the same results on each execution as the checkstyle > does. > Summary: > - add new checkstyle rule; > - update IDE's appropriate built-in inspections configurations; > - update development code-style web page and wiki; -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18089) The source code must obey the avoid star import checkstyle rule
[ https://issues.apache.org/jira/browse/CASSANDRA-18089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18089: Resolution: (was: Won't Fix) Status: Open (was: Resolved) > The source code must obey the avoid star import checkstyle rule > --- > > Key: CASSANDRA-18089 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18089 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Cassandra has the code style rules regarding the classes import order: > [https://cassandra.apache.org/_/development/code_style.html] > Importing all classes from a package or static members from a class leads to > tight coupling between packages or classes and might lead to problems when a > new library version introduces name clashes. The advantage of explicitly > listing all imports from a package is that you can tell at a glance which > class you meant to use, which does reading and refactoring the source code > that much easier. > The checkstyle that is already used for checking the source code has a such > check and this check may be added to the config both for the production and > test source code: > https://checkstyle.sourceforge.io/config_imports.html#AvoidStaticImport > Besides adding a new checkstyle rule it may be more convenient for those > community members that are working with the code to reflect the same rule in > the IDE's inspection profiles (if it's possible), thus using the 'optimize > imports' will produce the same results on each execution as the checkstyle > does. > Summary: > - add new checkstyle rule; > - update IDE's appropriate built-in inspections configurations; > - update development code-style web page and wiki; -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18089) The source code must obey the avoid star import checkstyle rule
[ https://issues.apache.org/jira/browse/CASSANDRA-18089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-18089: Resolution: Duplicate Status: Resolved (was: Open) > The source code must obey the avoid star import checkstyle rule > --- > > Key: CASSANDRA-18089 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18089 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Cassandra has the code style rules regarding the classes import order: > [https://cassandra.apache.org/_/development/code_style.html] > Importing all classes from a package or static members from a class leads to > tight coupling between packages or classes and might lead to problems when a > new library version introduces name clashes. The advantage of explicitly > listing all imports from a package is that you can tell at a glance which > class you meant to use, which does reading and refactoring the source code > that much easier. > The checkstyle that is already used for checking the source code has a such > check and this check may be added to the config both for the production and > test source code: > https://checkstyle.sourceforge.io/config_imports.html#AvoidStaticImport > Besides adding a new checkstyle rule it may be more convenient for those > community members that are working with the code to reflect the same rule in > the IDE's inspection profiles (if it's possible), thus using the 'optimize > imports' will produce the same results on each execution as the checkstyle > does. > Summary: > - add new checkstyle rule; > - update IDE's appropriate built-in inspections configurations; > - update development code-style web page and wiki; -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18179) Update current trunk build.xml and conf scripts for JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679647#comment-17679647
]
Ekaterina Dimitrova commented on CASSANDRA-18179:
-
{quote}The 17869 patch changes ci-cassandra.a.o to test 11+17 on trunk, so it
needs to wait til 17 tests pass.
{quote}
Yeah, I meant it with the assumption we add a toggle and change things
incrementally as we were discussing on the ticket whether we want that or not.
(to be discussed and decided) In the current state directly switching to 11+17,
indeed, this won't work.
{quote}Quick work around is to add a mention of CASSANDRA_USE_JDK11 in a
comment in this ticket's patch.
{quote}
That should probably work (let's test) if we really want to have this committed
now despite we are not being able to still compile and run CI (even with still
broken tests) until CASSANDRA-17281 lands. It seems that will unblock
CASSANDRA-18133 but not JDK17 broader testing (people still need to at least
comment out the scripted UDF related classes in their branches)
> Update current trunk build.xml and conf scripts for JDK17
> -
>
> Key: CASSANDRA-18179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18179
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.x
>
>
> To support JDK17 we need to make changes to build.xml and our scripts. There
> is a preliminary patch which makes a switch from JDK8+JDK11 to JDK11+JDK17
> but it will need a change considering CASSANDRA-18133
> CC [~mck]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18089) The source code must obey the avoid star import checkstyle rule
[ https://issues.apache.org/jira/browse/CASSANDRA-18089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679646#comment-17679646 ] Maxim Muzafarov commented on CASSANDRA-18089: - [~e.dimitrova] you're right. The work will be completed under CASSANDRA-17925 So, yes, probably the "duplicate" status is more correct here. > The source code must obey the avoid star import checkstyle rule > --- > > Key: CASSANDRA-18089 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18089 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Cassandra has the code style rules regarding the classes import order: > [https://cassandra.apache.org/_/development/code_style.html] > Importing all classes from a package or static members from a class leads to > tight coupling between packages or classes and might lead to problems when a > new library version introduces name clashes. The advantage of explicitly > listing all imports from a package is that you can tell at a glance which > class you meant to use, which does reading and refactoring the source code > that much easier. > The checkstyle that is already used for checking the source code has a such > check and this check may be added to the config both for the production and > test source code: > https://checkstyle.sourceforge.io/config_imports.html#AvoidStaticImport > Besides adding a new checkstyle rule it may be more convenient for those > community members that are working with the code to reflect the same rule in > the IDE's inspection profiles (if it's possible), thus using the 'optimize > imports' will produce the same results on each execution as the checkstyle > does. > Summary: > - add new checkstyle rule; > - update IDE's appropriate built-in inspections configurations; > - update development code-style web page and wiki; -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18179) Update current trunk build.xml and conf scripts for JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679645#comment-17679645 ] Michael Semb Wever commented on CASSANDRA-18179: bq. so my understanding is we need to block this ticket on the commit of CASSANDRA-17869. Thanks for spotting this. Actually no. The 17869 patch changes ci-cassandra.a.o to test 11+17 on trunk, so it needs to wait til 17 tests pass. Quick work around is to add a mention of CASSANDRA_USE_JDK11 in a comment in this ticket's patch. > Update current trunk build.xml and conf scripts for JDK17 > - > > Key: CASSANDRA-18179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18179 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.x > > > To support JDK17 we need to make changes to build.xml and our scripts. There > is a preliminary patch which makes a switch from JDK8+JDK11 to JDK11+JDK17 > but it will need a change considering CASSANDRA-18133 > CC [~mck] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18179) Update current trunk build.xml and conf scripts for JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679644#comment-17679644
]
Ekaterina Dimitrova commented on CASSANDRA-18179:
-
{quote}What will break is where scripts/tools grep the build.xml for
CASSANDRA_USE_JDK11 as a way to detect if jdk11 is possible.
{quote}
Yes, thanks for bearing with me. Indeed, his issue you already solved in
CASSANDRA-17869 so my understanding is we need to block this ticket on the
commit of CASSANDRA-17869.
Quick grep of the current CCM master branch confirmed we do not grep it in CCM:
{code:java}
$ grep -r "CASSANDRA_USE_JDK11" *
Binary file ccmlib/__pycache__/common.cpython-310.pyc matches
Binary file ccmlib/__pycache__/common.cpython-38.pyc matches
ccmlib/common.py:if 'CASSANDRA_USE_JDK11' not in os_env:
Binary file tests/__pycache__/test_lib.cpython-310.pyc matches
Binary file tests/__pycache__/test_lib.cpython-38-PYTEST.pyc matches
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
Binary file tests/test_lib.pyc matches
Binary file tests/ccmlib/__pycache__/common.cpython-310.pyc matches
tests/ccmlib/common.py:if 'CASSANDRA_USE_JDK11' not in os_env:
{code}
> Update current trunk build.xml and conf scripts for JDK17
> -
>
> Key: CASSANDRA-18179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18179
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.x
>
>
> To support JDK17 we need to make changes to build.xml and our scripts. There
> is a preliminary patch which makes a switch from JDK8+JDK11 to JDK11+JDK17
> but it will need a change considering CASSANDRA-18133
> CC [~mck]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18179) Update current trunk build.xml and conf scripts for JDK17
[
https://issues.apache.org/jira/browse/CASSANDRA-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679644#comment-17679644
]
Ekaterina Dimitrova edited comment on CASSANDRA-18179 at 1/22/23 8:55 PM:
--
{quote}What will break is where scripts/tools grep the build.xml for
CASSANDRA_USE_JDK11 as a way to detect if jdk11 is possible.
{quote}
Yes, thanks for bearing with me. Indeed, this issue you already solved in
CASSANDRA-17869 so my understanding is we need to block this ticket on the
commit of CASSANDRA-17869.
Quick grep of the current CCM master branch confirmed we do not grep it in CCM:
{code:java}
$ grep -r "CASSANDRA_USE_JDK11" *
Binary file ccmlib/__pycache__/common.cpython-310.pyc matches
Binary file ccmlib/__pycache__/common.cpython-38.pyc matches
ccmlib/common.py:if 'CASSANDRA_USE_JDK11' not in os_env:
Binary file tests/__pycache__/test_lib.cpython-310.pyc matches
Binary file tests/__pycache__/test_lib.cpython-38-PYTEST.pyc matches
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
Binary file tests/test_lib.pyc matches
Binary file tests/ccmlib/__pycache__/common.cpython-310.pyc matches
tests/ccmlib/common.py:if 'CASSANDRA_USE_JDK11' not in os_env:
{code}
was (Author: e.dimitrova):
{quote}What will break is where scripts/tools grep the build.xml for
CASSANDRA_USE_JDK11 as a way to detect if jdk11 is possible.
{quote}
Yes, thanks for bearing with me. Indeed, his issue you already solved in
CASSANDRA-17869 so my understanding is we need to block this ticket on the
commit of CASSANDRA-17869.
Quick grep of the current CCM master branch confirmed we do not grep it in CCM:
{code:java}
$ grep -r "CASSANDRA_USE_JDK11" *
Binary file ccmlib/__pycache__/common.cpython-310.pyc matches
Binary file ccmlib/__pycache__/common.cpython-38.pyc matches
ccmlib/common.py:if 'CASSANDRA_USE_JDK11' not in os_env:
Binary file tests/__pycache__/test_lib.cpython-310.pyc matches
Binary file tests/__pycache__/test_lib.cpython-38-PYTEST.pyc matches
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
tests/test_lib.py:
os_env={'CASSANDRA_USE_JDK11': 'true'})
Binary file tests/test_lib.pyc matches
Binary file tests/ccmlib/__pycache__/common.cpython-310.pyc matches
tests/ccmlib/common.py:if 'CASSANDRA_USE_JDK11' not in os_env:
{code}
> Update current trunk build.xml and conf scripts for JDK17
> -
>
> Key: CASSANDRA-18179
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18179
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Ekaterina Dimitrova
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.x
>
>
> To support JDK17 we need to make changes to build.xml and our scripts. There
> is a preliminary patch which makes a switch from JDK8+JDK11 to JDK11+JDK17
> but it will need a change considering CASSANDRA-18133
> CC [~mck]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18089) The source code must obey the avoid star import checkstyle rule
[ https://issues.apache.org/jira/browse/CASSANDRA-18089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679642#comment-17679642 ] Ekaterina Dimitrova commented on CASSANDRA-18089: - Thanks [~mmuzaf] for driving this work! Do I understand correct that you plan just to implement the rules as part of CASSANDRA-17925, and not really cancel the work? In that case I think we should mark this ticket as duplicate of CASSANDRA-17925, and not WON'T FIX? > The source code must obey the avoid star import checkstyle rule > --- > > Key: CASSANDRA-18089 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18089 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Cassandra has the code style rules regarding the classes import order: > [https://cassandra.apache.org/_/development/code_style.html] > Importing all classes from a package or static members from a class leads to > tight coupling between packages or classes and might lead to problems when a > new library version introduces name clashes. The advantage of explicitly > listing all imports from a package is that you can tell at a glance which > class you meant to use, which does reading and refactoring the source code > that much easier. > The checkstyle that is already used for checking the source code has a such > check and this check may be added to the config both for the production and > test source code: > https://checkstyle.sourceforge.io/config_imports.html#AvoidStaticImport > Besides adding a new checkstyle rule it may be more convenient for those > community members that are working with the code to reflect the same rule in > the IDE's inspection profiles (if it's possible), thus using the 'optimize > imports' will produce the same results on each execution as the checkstyle > does. > Summary: > - add new checkstyle rule; > - update IDE's appropriate built-in inspections configurations; > - update development code-style web page and wiki; -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18179) Update current trunk build.xml and conf scripts for JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679641#comment-17679641 ] Michael Semb Wever commented on CASSANDRA-18179: bq. I just read through the patch again and I still think we need to update CCM in parallel as it considers CASSANDRA_USE_JDK11 here CASSANDRA_USE_JDK11 can still be set in this situation. It's the build scripts that will remove the setting of that flag, not this build.xml patch. What will break is where scripts/tools grep the build.xml for CASSANDRA_USE_JDK11 as a way to detect if jdk11 is possible. Does ccm do that anywhere? > Update current trunk build.xml and conf scripts for JDK17 > - > > Key: CASSANDRA-18179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18179 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.x > > > To support JDK17 we need to make changes to build.xml and our scripts. There > is a preliminary patch which makes a switch from JDK8+JDK11 to JDK11+JDK17 > but it will need a change considering CASSANDRA-18133 > CC [~mck] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[
https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679638#comment-17679638
]
Ekaterina Dimitrova edited comment on CASSANDRA-17964 at 1/22/23 8:32 PM:
--
{quote}I believe that nobody is looking at this as it is a regression. It would
be a regression if a respective test was passing and it started to fail. But
these tests are technically failing already, we are just making it visible.
{quote}
That's what I think too.
{quote}[~e.dimitrova] We may indeed not ignore them if that is what you prefer.
Nothing against that. The obvious consequence of doing so is that they would
start to be visible as failures in the test results pretty much constantly
until they are fixed.
{quote}
I will leave the final decisions to you and the reviewers. It is indeed a
matter of visibility. What I was wondering is why adding a precedent, to
silence failing tests? What would be the rationality? This reminds me of the
case when [~dcapwell] found a long-term issue with DTests framework which led
to more failing tests. Some of those failing tests are still out there with
associated tickets for pre-4.0, for example? I believe there was something
around a repair bug being exposed for example.
was (Author: e.dimitrova):
{quote}I believe that nobody is looking at this as it is a regression. It would
be a regression if a respective test was passing and it started to fail. But
these tests are technically failing already, we are just making it visible.
{quote}
That's what I think too.
{quote}[~e.dimitrova] We may indeed not ignore them if that is what you prefer.
Nothing against that. The obvious consequence of doing so is that they would
start to be visible as failures in the test results pretty much constantly
until they are fixed.
{quote}
I will leave the final decisions to you and the reviewers. It is indeed a
matter of visibility. What I was wondering is why adding a precedent, to
silence failing tests? What would be the rationality?
> Some tests are never executed due to naming violation - fix it and add
> checkstyle where applicable
> --
>
> Key: CASSANDRA-17964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17964
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Ruslan Fomkin
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java]
> doesn't follow naming convention to be run as unit tests and, thus, is never
> run.
> The rule in build expects names as `*Test`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18089) The source code must obey the avoid star import checkstyle rule
[ https://issues.apache.org/jira/browse/CASSANDRA-18089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-18089: Resolution: Won't Fix Status: Resolved (was: Open) I've cancelled the patch. According to the dev-list discussion we've decided to implement at once both of the checkstyle rules: AvoidStarImport and ImportOrder. This is the issue to reference to: CASSANDRA-17925 > The source code must obey the avoid star import checkstyle rule > --- > > Key: CASSANDRA-18089 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18089 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Cassandra has the code style rules regarding the classes import order: > [https://cassandra.apache.org/_/development/code_style.html] > Importing all classes from a package or static members from a class leads to > tight coupling between packages or classes and might lead to problems when a > new library version introduces name clashes. The advantage of explicitly > listing all imports from a package is that you can tell at a glance which > class you meant to use, which does reading and refactoring the source code > that much easier. > The checkstyle that is already used for checking the source code has a such > check and this check may be added to the config both for the production and > test source code: > https://checkstyle.sourceforge.io/config_imports.html#AvoidStaticImport > Besides adding a new checkstyle rule it may be more convenient for those > community members that are working with the code to reflect the same rule in > the IDE's inspection profiles (if it's possible), thus using the 'optimize > imports' will produce the same results on each execution as the checkstyle > does. > Summary: > - add new checkstyle rule; > - update IDE's appropriate built-in inspections configurations; > - update development code-style web page and wiki; -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[
https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679638#comment-17679638
]
Ekaterina Dimitrova edited comment on CASSANDRA-17964 at 1/22/23 8:32 PM:
--
{quote}I believe that nobody is looking at this as it is a regression. It would
be a regression if a respective test was passing and it started to fail. But
these tests are technically failing already, we are just making it visible.
{quote}
That's what I think too.
{quote}[~e.dimitrova] We may indeed not ignore them if that is what you prefer.
Nothing against that. The obvious consequence of doing so is that they would
start to be visible as failures in the test results pretty much constantly
until they are fixed.
{quote}
I will leave the final decisions to you and the reviewers. It is indeed a
matter of visibility. What I was wondering is why adding a precedent, to
silence failing tests? What would be the rationality? This reminds me of the
case when [~dcapwell] found a long-term issue with DTests framework which led
to more failing tests after the bug was fixed. Some of those failing tests are
still out there with associated tickets for pre-4.0, for example? I believe
there was something around a repair bug being exposed for example.
was (Author: e.dimitrova):
{quote}I believe that nobody is looking at this as it is a regression. It would
be a regression if a respective test was passing and it started to fail. But
these tests are technically failing already, we are just making it visible.
{quote}
That's what I think too.
{quote}[~e.dimitrova] We may indeed not ignore them if that is what you prefer.
Nothing against that. The obvious consequence of doing so is that they would
start to be visible as failures in the test results pretty much constantly
until they are fixed.
{quote}
I will leave the final decisions to you and the reviewers. It is indeed a
matter of visibility. What I was wondering is why adding a precedent, to
silence failing tests? What would be the rationality? This reminds me of the
case when [~dcapwell] found a long-term issue with DTests framework which led
to more failing tests. Some of those failing tests are still out there with
associated tickets for pre-4.0, for example? I believe there was something
around a repair bug being exposed for example.
> Some tests are never executed due to naming violation - fix it and add
> checkstyle where applicable
> --
>
> Key: CASSANDRA-17964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17964
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Ruslan Fomkin
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java]
> doesn't follow naming convention to be run as unit tests and, thus, is never
> run.
> The rule in build expects names as `*Test`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18089) The source code must obey the avoid star import checkstyle rule
[ https://issues.apache.org/jira/browse/CASSANDRA-18089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated CASSANDRA-18089: Status: Open (was: Patch Available) > The source code must obey the avoid star import checkstyle rule > --- > > Key: CASSANDRA-18089 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18089 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > Cassandra has the code style rules regarding the classes import order: > [https://cassandra.apache.org/_/development/code_style.html] > Importing all classes from a package or static members from a class leads to > tight coupling between packages or classes and might lead to problems when a > new library version introduces name clashes. The advantage of explicitly > listing all imports from a package is that you can tell at a glance which > class you meant to use, which does reading and refactoring the source code > that much easier. > The checkstyle that is already used for checking the source code has a such > check and this check may be added to the config both for the production and > test source code: > https://checkstyle.sourceforge.io/config_imports.html#AvoidStaticImport > Besides adding a new checkstyle rule it may be more convenient for those > community members that are working with the code to reflect the same rule in > the IDE's inspection profiles (if it's possible), thus using the 'optimize > imports' will produce the same results on each execution as the checkstyle > does. > Summary: > - add new checkstyle rule; > - update IDE's appropriate built-in inspections configurations; > - update development code-style web page and wiki; -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[
https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679638#comment-17679638
]
Ekaterina Dimitrova commented on CASSANDRA-17964:
-
{quote}I believe that nobody is looking at this as it is a regression. It would
be a regression if a respective test was passing and it started to fail. But
these tests are technically failing already, we are just making it visible.
{quote}
That's what I think too.
{quote}[~e.dimitrova] We may indeed not ignore them if that is what you prefer.
Nothing against that. The obvious consequence of doing so is that they would
start to be visible as failures in the test results pretty much constantly
until they are fixed.
{quote}
I will leave the final decisions to you and the reviewers. It is indeed a
matter of visibility. What I was wondering is why adding a precedent, to
silence failing tests? What would be the rationality?
> Some tests are never executed due to naming violation - fix it and add
> checkstyle where applicable
> --
>
> Key: CASSANDRA-17964
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17964
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Ruslan Fomkin
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java]
> doesn't follow naming convention to be run as unit tests and, thus, is never
> run.
> The rule in build expects names as `*Test`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17925) Java source code should have sorted imports as defined in the codestyle
[
https://issues.apache.org/jira/browse/CASSANDRA-17925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated CASSANDRA-17925:
Change Category: Code Clarity
Complexity: Normal
Component/s: Build
Status: Open (was: Triage Needed)
> Java source code should have sorted imports as defined in the codestyle
> ---
>
> Key: CASSANDRA-17925
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17925
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Stefan Miklosovic
>Assignee: Maxim Muzafarov
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After we cleaned all unused imports in CASSANDRA-17876, there is one more
> task remaining to be done - to add checkstyle for imports order and enforce
> this on build time.
> When the project is imported into IDEA, there is a helper target on Ant
> called "generate-idea-files". ide/idea/codeStyleSettings.xml contains this:
> {code:java}
>
>
>
>
>
> static="false" />
> static="false" />
> static="false" />
> static="false" />
>
>
>
>
>
>
>
>
> {code}
> This code style is also mentioned in the web page here (minus some details
> which are present in above configuration snippet but not on the web page):
> [https://cassandra.apache.org/_/development/code_style.html] (at the very
> bottom).
> However, when one runs "Optimise imports" in the context menu after
> right-clicking on org.cassandra.apache package, it will refactor the imports
> and it results with hundreds of changes.
> This means that the source code, as-is, does not adhere to the self-imposed
> code style we ship for IDEA.
> If we fix this, we should add checkstyle for it like this:
> {code:java}
>
>value="/(^java\.|javax)/,/(com\.google\.common|org\.apache\.log4j|org\.apache\.commons|org\.cliffc\.high_scale_lib|org\.junit|org\.slf4j)/"/>
>
>
>
>
>
>
> {code}
> This checkstyle on import order will pass on the source code we run the
> import optimization in the context menu on.
> There is also no enforcement on "all star" imports (org.some.pkg.*).
> Checkstyle has specific module for this:
> [https://checkstyle.org/config_imports.html#AvoidStarImport]
> I propose we should stop to use all-star imports. Same argument holds as
> described there: Rationale: Importing all classes from a package or static
> members from a class leads to tight coupling between packages or classes and
> might lead to problems when a new version of a library introduces name
> clashes.
> This should be applied to test checktyle as well and the source code should
> be refactored on imports too.
> This should be done on cassandra-4.1 as well as for trunk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[ https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679635#comment-17679635 ] Stefan Miklosovic commented on CASSANDRA-17964: --- [~e.dimitrova] We may indeed not ignore them if that is what you prefer. Nothing against that. The obvious consequence of doing so is that they would start to be visible as failures in the test results pretty much constantly until they are fixed. I believe that nobody is looking at this as it is a regression. It would be a regression if a respective test was passing and it started to fail. But these tests are technically failing already, we are just making it visible. > Some tests are never executed due to naming violation - fix it and add > checkstyle where applicable > -- > > Key: CASSANDRA-17964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17964 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java] > doesn't follow naming convention to be run as unit tests and, thus, is never > run. > The rule in build expects names as `*Test`. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18179) Update current trunk build.xml and conf scripts for JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679634#comment-17679634 ] Ekaterina Dimitrova commented on CASSANDRA-18179: - bq. Yes. the point of the patch's approach is that we can introduce jdk17 now, regardless of it not yet compiling. This makes it a little easier to coordinate the changes onwards in other repos. I just read through the patch again and I still think we need to update CCM in parallel as it considers CASSANDRA_USE_JDK11 [here|https://github.com/riptano/ccm/blob/master/ccmlib/common.py#L915] > Update current trunk build.xml and conf scripts for JDK17 > - > > Key: CASSANDRA-18179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18179 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.x > > > To support JDK17 we need to make changes to build.xml and our scripts. There > is a preliminary patch which makes a switch from JDK8+JDK11 to JDK11+JDK17 > but it will need a change considering CASSANDRA-18133 > CC [~mck] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[ https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679632#comment-17679632 ] Ekaterina Dimitrova edited comment on CASSANDRA-17964 at 1/22/23 7:28 PM: -- bq. I am becoming a little bit irritated by this ticket already. I am constantly waiting for something to happen and people changing their minds on the last notice. Last thing I want is to irritate you or demand anything. The opposite - I want to thank you guys for tackling this problem! bq. Because the work in this ticket has nothing to do with them failing. It is about introducing an Ant task and respective target which is checking how they are called, not if they are run successfully. Totally agree with you I also did not have the intention to imply that you should fix those tests. Not at all! You solved the problem in hand. That those tests failed with no one realizing that because they were not run is not part of the problem you are solving here. More like - I was wondering what is the rationality to add @ignore if we are opening tickets and they need to be fixed? Same as every other ticket we have for failing/flaky test. That's all I meant. I was wondering whether they are maybe just too many and you don't want to add too much noise or so? was (Author: e.dimitrova): bq. I am becoming a little bit irritated by this ticket already. I am constantly waiting for something to happen and people changing their minds on the last notice. Last thing I want is to irritate you or demand anything. The opposite - I want to thank you guys for tackling this problem! bq. Because the work in this ticket has nothing to do with them failing. It is about introducing an Ant task and respective target which is checking how they are called, not if they are run successfully. Totally agree with you I also did not have the intention to imply that you should fix those tests. Not at all! You solved the problem in hand. That those tests failed with no one realizing that because they were not run is not part of the problem you are solving here. More like - I was wondering what is the rationality to add @ignore if we are opening tickets and they need to be fixed? Same as every other ticket we have for failing/flaky test. That's all I meant. > Some tests are never executed due to naming violation - fix it and add > checkstyle where applicable > -- > > Key: CASSANDRA-17964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17964 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java] > doesn't follow naming convention to be run as unit tests and, thus, is never > run. > The rule in build expects names as `*Test`. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[ https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679632#comment-17679632 ] Ekaterina Dimitrova commented on CASSANDRA-17964: - bq. I am becoming a little bit irritated by this ticket already. I am constantly waiting for something to happen and people changing their minds on the last notice. Last thing I want is to irritate you or demand anything. The opposite - I want to thank you guys for tackling this problem! bq. Because the work in this ticket has nothing to do with them failing. It is about introducing an Ant task and respective target which is checking how they are called, not if they are run successfully. Totally agree with you I also did not have the intention to imply that you should fix those tests. Not at all! You solved the problem in hand. That those tests failed with no one realizing that because they were not run is not part of the problem you are solving here. More like - I was wondering what is the rationality to add @ignore if we are opening tickets and they need to be fixed? Same as every other ticket we have for failing/flaky test. That's all I meant. > Some tests are never executed due to naming violation - fix it and add > checkstyle where applicable > -- > > Key: CASSANDRA-17964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17964 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java] > doesn't follow naming convention to be run as unit tests and, thus, is never > run. > The rule in build expects names as `*Test`. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17964) Some tests are never executed due to naming violation - fix it and add checkstyle where applicable
[ https://issues.apache.org/jira/browse/CASSANDRA-17964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679629#comment-17679629 ] Stefan Miklosovic commented on CASSANDRA-17964: --- Because the work in this ticket has nothing to do with them failing. It is about introducing an Ant task and respective target which is checking how they are called, not if they are run successfully. I am becoming a little bit irritated by this ticket already. I am constantly waiting for something to happen and people changing their minds on the last notice. Could not we just introduce the Ant task and file the tickets? I think this is pretty much standard way of doing it? > Some tests are never executed due to naming violation - fix it and add > checkstyle where applicable > -- > > Key: CASSANDRA-17964 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17964 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Ruslan Fomkin >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 2h 50m > Remaining Estimate: 0h > > [BatchTests|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/cql3/BatchTests.java] > doesn't follow naming convention to be run as unit tests and, thus, is never > run. > The rule in build expects names as `*Test`. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (fe794cc18 -> 4b891a24f)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard fe794cc18 generate docs for 5dd84ab2 new 4b891a24f generate docs for 5dd84ab2 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (fe794cc18) \ N -- N -- N refs/heads/asf-staging (4b891a24f) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4970898 -> 4970898 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18185) Accumulate all the `docs` PR from GitHub into a single patch
[ https://issues.apache.org/jira/browse/CASSANDRA-18185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679581#comment-17679581 ] Nikita Eshkeev commented on CASSANDRA-18185: Here is [the link|https://github.com/apache/cassandra/pull/2062] to the patch > Accumulate all the `docs` PR from GitHub into a single patch > > > Key: CASSANDRA-18185 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18185 > Project: Cassandra > Issue Type: Improvement >Reporter: Nikita Eshkeev >Assignee: Nikita Eshkeev >Priority: Normal > Time Spent: 10m > Remaining Estimate: 0h > > In order to make it easier to review the `docs` labeled pull-requests all of > them should be accumulated into a single commit as per the > [request|https://github.com/apache/cassandra/pull/2062#issuecomment-1385002289] > from [~smiklosovic] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18185) Accumulate all the `docs` PR from GitHub into a single patch
Nikita Eshkeev created CASSANDRA-18185: -- Summary: Accumulate all the `docs` PR from GitHub into a single patch Key: CASSANDRA-18185 URL: https://issues.apache.org/jira/browse/CASSANDRA-18185 Project: Cassandra Issue Type: Improvement Reporter: Nikita Eshkeev Assignee: Nikita Eshkeev In order to make it easier to review the `docs` labeled pull-requests all of them should be accumulated into a single commit as per the [request|https://github.com/apache/cassandra/pull/2062#issuecomment-1385002289] from [~smiklosovic] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18179) Update current trunk build.xml and conf scripts for JDK17
[ https://issues.apache.org/jira/browse/CASSANDRA-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679557#comment-17679557 ] Michael Semb Wever commented on CASSANDRA-18179: bq. Considering trunk does not yet compile I guess we can just leave a comment about that in build.xml. And considering that I do not see it a breaking change that CCM is still not ready as we can't even compile...yet Yes. the point of the patch's approach is that we can introduce jdk17 now, regardless of it not yet compiling. This makes it a little easier to coordinate the changes onwards in other repos. > Update current trunk build.xml and conf scripts for JDK17 > - > > Key: CASSANDRA-18179 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18179 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.x > > > To support JDK17 we need to make changes to build.xml and our scripts. There > is a preliminary patch which makes a switch from JDK8+JDK11 to JDK11+JDK17 > but it will need a change considering CASSANDRA-18133 > CC [~mck] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
