ci(java): build JNI release package #2516
Conversation
eddyxu
changed the title
eddyxu
force-pushed
the
lei/jni_multiplatform
branch
from
70fca48
to
12303fd
Compare
|
#2524 the created jar can be used without the glibc issue |
| - .github/workflows/java-publish.yml | ||
|
|
||
| jobs: | ||
| macos-arm64: |
There was a problem hiding this comment.
i felt like it should not be 3 jobs. but instead we should have 3 run matrix and at the very end we need to copy all 3 share lib (linux-x86, linux-arm, macos-arm) into the same fat jar?
this will still release 3 different JAR IIUC?
There was a problem hiding this comment.
yes, if we call mvn deploy in three different job, we have to release 3 different jars (with different names?).
I am not sure that mvn will resolve dependency based on the system, like what pypi does.
There was a problem hiding this comment.
we should have 3 run matrix and at the very end we need to copy all 3 share lib (linux-x86, linux-arm, macos-arm) into the same fat jar?
Put them into separate jobs, so that i can pass upload-artifcat/download-artifcat between the jobs. If we just run 3 parallel metrics, we need the 4th one to download the artifact?
Signed-off-by: BubbleCal <bubble-cal@outlook.com>
- replace RoaringBitmap with BitVec - use pool to avoid allocating bitset for each query with prefilter - fall back to flat search if too many rows filtered out - prefetch with flat search --------- Signed-off-by: BubbleCal <bubble-cal@outlook.com>
This PR adds a new kind of scalar index, the LABEL_LIST scalar index. A label list index can only be created on list columns (the item data type has to be one of the data types that can be used for btree/bitmap indices). The label list index can speed up array_has_any and array_has_all queries. This is useful for tag-like columns where each row has some number of labels and the overall cardinality of the labels is relatively low (the index in-memory size will depend on the cardinality of the labels). This PR also introduces the idea that different scalar indices may support different types of queries. There is now `SargableQuery` (what is used by btree and bitmap) and `LabelListQuery` (used by the new label list index). Going forward we should probably break the FullTextQuery out of `SargableQuery` and into its own query type.
|
i think the problem is similar to: rust-lang/rust#57497 <-- during the CI pipeline somehow GLIBC_VERSION 2.38 was pulled in. but it is not actually a package available in ubuntu. so unless we also setup rust build env in the same i wasn't able to do so. could we detect which step in the CI job actually pull in the GLIBC 2.38? if so i can replicate the step on the other CI side |
Provide a Github action workflow to release multi-platform JNI.
We will keep releasing 0.0.x version until Java SDK has decent feature parity.