[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068962#comment-17068962 ] Alex Petrov commented on CASSANDRA-15539: - Thank you for reviews! Committed to 2.2 with [1f72cc6197187abac5b1f70a19589dd4883e8d98|https://github.com/apache/cassandra/commit/1f72cc6197187abac5b1f70a19589dd4883e8d98] and merged up to [3.0|https://github.com/apache/cassandra/commit/c2cfebf44f93af061131d73e4dcbf2a9ff582fe8], [3.11|https://github.com/apache/cassandra/commit/a7820d103956ae72ffbb90f39fe6f2452658a708] and [trunk|https://github.com/apache/cassandra/commit/0934730c2b89b2cc3cb430e4f60fc15b67af7e9f]. Code for dtest-api now lives under https://github.com/apache/cassandra-in-jvm-dtest-api > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 13h 20m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17068858#comment-17068858 ] David Capwell commented on CASSANDRA-15539: --- +1 with feedback. There are a few things I want reverted and [~ifesdjeen] promised to do on-commit, so I trust he will =) There are things I want to have improved, but I am fine holding off and tacking in other JIRAs. > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 13h 20m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17065309#comment-17065309 ] David Capwell commented on CASSANDRA-15539: --- reviewed again with feedback. > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 8h > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17062932#comment-17062932 ] David Capwell commented on CASSANDRA-15539: --- Right now I am only reviewing trunk as I assume all branches are the same, once trunk is good ill look at the rest. Reviewed again, but non of my comments were addressed, only looks like you rebased to pick up the latest changes for repair. > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 2h 20m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17062831#comment-17062831 ] Alex Petrov commented on CASSANDRA-15539: - [~dcapwell] [~djoshi] thank you for the review. I've rebased all branches and addressed all comments. CI is now green. It'd be great to move quickly and commit it shortly to avoid new rebases, since they're very time consuming. Thank you for understanding! > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17056242#comment-17056242 ] Dinesh Joshi commented on CASSANDRA-15539: -- [~ifesdjeen] i went through the patches and they seem ok so overall I am +1 on it. I don't have strong opinions on the way these patches are being orchestrated for review. If there are minor issues that need to be addressed lets fix them here. However, I am also ok fixing them as follow on patches to this ticket. Rebasing 4 branches in sync is very cumbersome. > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17045822#comment-17045822 ] David Capwell commented on CASSANDRA-15539: --- I reviewed the new repo and trunk (left comments, main ones are here), and what I am seeing is that your branches are stale which look to cause you to revert all changes since you started. Looking at the changes I see a group of changes 1) refactor to lower the dependency on Cassandra 2) general refactors to API for reasons (.verbs to .filters, etc., not clear if this is caused by being stale) 3) tests getting deleted (please don't delete tests) 4) shuffle files from one location to the next. Given what you are trying to do here, I personally feel you will go faster if you break this into sub tasks and commit each in isolation. For example, #1 and #2 could be committed quickly, followed by #4. #4 causes issues the longer the branch lives which is why I think #3 is happening. > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Time Spent: 1h 50m > Remaining Estimate: 0h > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17044276#comment-17044276 ] Alex Petrov commented on CASSANDRA-15539: - What was done so far: 1. Create a new library that publishes a new in-jvm-dtest API out-of-tree. 2. Publish artifact for a version 0.0.1-SNAPSHOT of API library 3. Bring API library to be used in Cassandra, without migrating the tests out 4. Create a patch that migrates tests out of tree, that uses 1.0.0 version of the API library I did run tests out of tree on all branches locally, too. Now we only have to set up CI to run it. Patches for all branches: |2.2|[patch|https://github.com/ifesdjeen/cassandra/tree/CASSANDRA-15539-2.2-oss]|[CI|https://circleci.com/gh/ifesdjeen/cassandra/tree/CASSANDRA-15539-2.2-oss]| |3.0|[patch|https://github.com/ifesdjeen/cassandra/tree/CASSANDRA-15539-3.0-oss]|[CI|https://circleci.com/gh/ifesdjeen/cassandra/tree/CASSANDRA-15539-3.0-oss]| |3.11|[patch|https://github.com/ifesdjeen/cassandra/tree/CASSANDRA-15539-3.11-oss]|[CI|https://circleci.com/gh/ifesdjeen/cassandra/tree/CASSANDRA-15539-3.11-oss]| |trunk|[patch|https://github.com/ifesdjeen/cassandra/tree/CASSANDRA-15539-trunk-oss]|[CI|https://circleci.com/gh/ifesdjeen/cassandra/tree/CASSANDRA-15539-trunk-oss]| > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032028#comment-17032028 ] David Capwell commented on CASSANDRA-15539: --- bq. I would say we should split the process in two tree logical parts: first one is to commit API extraction, while leaving all the tests in-tree, then committing tests to a separate repo, and finally removing the tests. This allows us to work around the chicken-and-egg problem of two repositories sort of depending on each other. Makes sense. Between each phase we will need to update Jenkins and CircleCI. bq. I'm also thinking about how to make it fully frictionless for PR builds that change both the library and tests, especially with snapshot builds. This means that we might end up with tests relying not on the latest (SNAPSHOT) version of the API, but rather relying on the latest published (RELEASE) version of the API. Let's say we have published in-jvm-dtest-api of version 0.0.2 and started using it in Cassandra. If we first commit the part that runs in-jvm dtests out of tree, it will try to run tests for all branches against 0.0.2, even though Cassandra with 0.0.2 couldn't have been built by then, since 0.0.2 wasn't published yet. So we will have to first commit the API changes, then bump version of API dep in Cassandra, and only then bump the version of API dep in the library that runs in-jvm-tests out of tree. Thats one of the reasons I wanted the implementation in the new repo =D I think the better we get at having low level primitives in the core API the easier it will be to not require changes in the API; simple example is your recent interceptor patch, the existing filters can be based off that and we can build more on it, so wouldn't require updating the implementation. > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[
https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031406#comment-17031406
]
Alex Petrov commented on CASSANDRA-15539:
-
I would say we should split the process in two tree logical parts: first one is
to commit API extraction, while leaving all the tests in-tree, then committing
tests to a separate repo, and finally removing the tests. This allows us to
work around the chicken-and-egg problem of two repositories sort of depending
on each other.
I'm also thinking about how to make it fully frictionless for PR builds that
change both the library and tests, especially with snapshot builds. This means
that we might end up with tests relying not on the _latest_ version of the API,
but rather relying on the _latest published_ version of the API. Let's say we
have published {{in-jvm-dtest-api}} of version {{0.0.2}} and started using it
in Cassandra. If we first commit the part that runs in-jvm dtests out of tree,
it will try to run tests for all branches against 0.0.2, even though Cassandra
with 0.0.2 couldn't have been built by then, since 0.0.2 wasn't published yet.
So we will have to first commit the API changes, then bump version of API dep
in Cassandra, and only then bump the version of API dep in the library that
runs in-jvm-tests out of tree.
To be completely fair, I think that using this for PR builds is fine, as long
as we do not bump the version of the API. As soon as we bump the version, we
end up with a deadlock of dependencies and have to commit things step-by-step.
To summarize:
1. Create a new library that publishes a new in-jvm-dtest API out-of-tree.
2. Publish artifact for a version 1.0.0 of API library
3. Bring API library to be used in Cassandra, without migrating the tests out
4. Create a patch that migrates tests out of tree, that uses 1.0.0 version of
the API library
5. Run tests out of tree, make sure everything passes
6. Remove overlapping tests from the tree
When making changes to API library:
1. Locally, test that all branches work with the new version of the library
2. Publish a new version of the API library (say, 1.0.1)
3. Publish Cassandra branches that use 1.0.1 version of the library
4. Update version of the library used in out-of-tree test runner to 1.0.1
(since after before 4 is done, we'll be failing tests that try to link
cassandra against 1.0.1 since is built against 1.0.0, we can as well publish
the out-of-tree test runner during step 2, and simply wait until Cassandra
itself is published)
When making changes to Cassandra that do not change API library, we'll simlpy
trigger a in-jvm-dtest-runner on PR build, and do the same on commit.
When making changes to in-jvm-dtest-runner, we'll run tests for all branches,
assuming their version matches the expected one.
> Extract in-jvm API and tests out of Cassandra and into a separate repository
>
>
> Key: CASSANDRA-15539
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15539
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Alex Petrov
>Assignee: Alex Petrov
>Priority: Normal
>
> Extract in-jvm DTest _API_ and tests into a separate repository that is
> shared between Cassandra branches. Tests themselves should be buildable using
> just API, which is not the case now, since cluster creation relies on impl
> package, since we do not have factories / constructors in API.
> Main goals we’re trying to achieve:
> 1. We should be able to fail a build on API incompatibility between versions
> 2. Make it as easy as possible to detect break APIs between versions.
> 3. Make development of _tests_ based on in-jvm framework simpler
> 4. Reduce surface area of impact when making modifications to tests
> Potentially, we’d also like to use a plugin to detect API incompatibilities
> between in-jvm DTest API and in-branch implementations, and start running
> tests using shared in-jvm test repository with each existing implementation
> in the branch. This entails both running tests for all branches whenever
> there’s a change in tests jar and running tests for a specific branch
> whenever the branch has changed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030909#comment-17030909 ] David Capwell commented on CASSANDRA-15539: --- Patch mostly LGTM, the main concern I have is with the rollout; we should plan for how to get from now to the desired state without impacting builds/CI. [~ifesdjeen] can you propose a way to do this? > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task > Components: Test/dtest >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, which is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15539) Extract in-jvm API and tests out of Cassandra and into a separate repository
[ https://issues.apache.org/jira/browse/CASSANDRA-15539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027464#comment-17027464 ] Alex Petrov commented on CASSANDRA-15539: - cc [~dcapwell] [~djoshi] [~drohrer] [~mck] > Extract in-jvm API and tests out of Cassandra and into a separate repository > > > Key: CASSANDRA-15539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15539 > Project: Cassandra > Issue Type: Task >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Extract in-jvm DTest _API_ and tests into a separate repository that is > shared between Cassandra branches. Tests themselves should be buildable using > just API, wwhich is not the case now, since cluster creation relies on impl > package, since we do not have factories / constructors in API. > Main goals we’re trying to achieve: > 1. We should be able to fail a build on API incompatibility between versions > 2. Make it as easy as possible to detect break APIs between versions. > 3. Make development of _tests_ based on in-jvm framework simpler > 4. Reduce surface area of impact when making modifications to tests > Potentially, we’d also like to use a plugin to detect API incompatibilities > between in-jvm DTest API and in-branch implementations, and start running > tests using shared in-jvm test repository with each existing implementation > in the branch. This entails both running tests for all branches whenever > there’s a change in tests jar and running tests for a specific branch > whenever the branch has changed. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
