Cuvs lucene move

[imotov]

Moves cuvs-lucene into java/cuvs-lucene folder of cuVs.

This is a preliminary PR to validate CI scripts. We'll need to rerun parts of the process and rebase the PR when we're ready to make the move. So, please ignore all changes in java/cuvs-lucene directory except for build-related changes.

Open questions:

• Do we want to have a separate cuvs-lucene-codeowners or do we use cuvs-java-codeowners?

Timeline for the move:

• Right after 26.08 release
  • Merge this PR to main with no-squash and move all new cuvs-lucene development to cuvs wi
  • Add a note to cuvs-lucene that all new development and all issues should be now go to this repo
• Between 26.08 release and 26.10 code freeze
  • Move all still relevant cuvs-lucene PRs and issue to cuvs repo, close the rest.
  • Update release process to publish cuvs-lucene jars from this project instead of cuvs-lucene
  • Remove references to the cuvs-lucene repo in various other parts of our infrastructure
    • rapids-metadata
    • workflows (nightly builds)
• After 26.10 code freeze and when all issue and PRs are move to this repo
  • Archive cuvs-lucene

Preparation script for cuvs-lucene:

git clone [git@github.com](mailto:git@github.com):NVIDIA/cuvs-lucene.git cuvs-lucene-move
cd cuvs-lucene-move
git filter-repo --to-subdirectory-filter java/cuvs-lucene --replace-message ../message-filter.txt
cd ../cuvs
git remote add cuvs-lucene-origin ../cuvs-lucene-move
git fetch cuvs-lucene-origin
git merge --allow-unrelated-histories cuvs-lucene-origin/main
# Comment message:
# Merge main branch of 'cuvs-lucene' into cuvs
git remote remove cuvs-lucene-origin

message-filter.txt

regex:(?<![\w/])#(\d{1,3})\b==>NVIDIA/cuvs-lucene#\1

See NVIDIA/cuvs-lucene#168

[imotov]

/ok to test b57e9c9

[imotov]

/ok to test f251a6a

[jameslamb]

I reviewed from the narrow perspective of build/packaging (ignored any of the code in java/ that looks like it's just directly moving from the cuvs-lucene repo, like the PR description mentions).

Left a few small suggestions, but overall this looks great from that perspective.

I put a DO NOT MERGE label on this to avoid anyone accidentally squash merging this, since you mentioned you want to no-squash merge it to preserve the commit history (contribution stats, git blame, etc.). When it's ready to merge and passing CI, anyone with write access can do that by removing that label then commenting /merge nosquash.

re: your questions about codeowners... that could probably be deferred to a separate PR. At least as of this, all the changes would already be covered by these rules:

cuvs/.github/CODEOWNERS

Lines 10 to 12 in cd4bbab

	#java code owners
	java/ @NVIDIA/cuvs-java-codeowners
	examples/java/ @NVIDIA/cuvs-java-codeowners

[jameslamb]

Can you do another pass over these lists please?

Most of them should include both ci/build_lucene.sh and ci/test_lucene.sh, I think.

For example, this line I'm commenting on is in a group called test_cpp which controls whether cuVS's C++ tests need to run in CI. A PR that only changes ci/build_lucene.sh shouldn't at all affect the output of those tests.

I know these lists can be a little tedious to maintain, but it's really worth it... cuVS's C++ test jobs can take 3+ hours to run 😫

[imotov]

That makes sense, but if I understand the logic correctly test_cpp should also include exclusions for ci/build_go.sh, ci/build_java.sh, !ci/build_python.sh, !ci/build_rust.sh, shouldn't it?

[cjnolet]

@imotov are we planning to bring over the original history from cuVS-lucene?

Trying to understand why we are asking for no squash merge.

[imotov]

Yes, my preference would be to squash all of my commits related to getting this in, while leaving all historical commits that I pulled from cuvs-lucene repo untouched. This will not add too much noise from me iterating here, but will preserve all history of cuvs-lucene project. Preserving history is definitely possible, and if you check out this PR's branch and run git blame on any cuvs-lucene file, you'll see the correct commits and authors. So, as long as we don't squash this PR the history will be preserved.

The script at the bottom of the PR description is what makes this possible. It rewrites all commits in the cuvs-lucene repo as if they had originally been applied under the java/lucene directory instead of the repository root, and it adjusts all unqualified issue and PR references in commit comments to point to the cuvs-lucene repository. This ensures that files with the same name (like README.md) in both repositories retain distinct histories, and prevents clashes between issues and PRs with the same numbers in the cuvs and cuvs-lucene repositories.

[imotov]

/ok to test d3d8475