Skip to content

Conversation

ScottDugas
Copy link
Collaborator

This moves things that were in fdb-extensions and needed for testing out into their own test-specific sub-project. The new project doesn't depend on any of the other sub-projects.

I left MultipleTransactions behind in the testFixtures. It currently depends on FDBError (which is part of fdb-extensions), and currently no other project is depending on it, so I felt that leaving it made sense.

This is in support of: #3574 -- see #3575 (comment)

This moves things that were in `fdb-extensions` and needed for testing
out into their own test-specific sub-project. The new project doesn't
depend on any of the other sub-projects.

I left `MultipleTransactions` behind in the testFixtures. It currently
depends on `FDBError` (which is part of fdb-extensions), and currently
no other project is depending on it, so I felt that leaving it
made sense.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TeamScale is complaining that we should not use varargs for cartesianProduct.
I think this is a valid usage of varargs, as per the explanation of the issue:

Varargs methods are a convenient way to define methods that require a variable number of arguments, but they should not be overused. They can produce confusing results if used inappropriately.

I think we should tolerate this usage and leave it as-is, but wanted am commenting here as a place for discussion.

I will note that cartesianProduct does have a private overload that takes and returns an incompatible type from the public method.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TeamScale is complaining that we should not use varargs for randomSeeds.
I think this is a valid usage of varargs, as per the explanation of the issue:

Varargs methods are a convenient way to define methods that require a variable number of arguments, but they should not be overused. They can produce confusing results if used inappropriately.

I think we should tolerate this usage and leave it as-is, but wanted am commenting here as a place for discussion.

@ScottDugas ScottDugas added the build improvement Improvement to the build system label Sep 24, 2025
I could not get javadoc to not complain, so I just escaped the @
and used <pre> by itself.
@ScottDugas

This comment was marked as outdated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build improvement Improvement to the build system

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant