Conversation
* Update gradle.yml Add debug to download of test modules * Update gradle.yml fixed indentation of lines 49,50 of gradle.yml * Update gradle.yml Change download url to be a variable rather than a secret. * Update gradle.yml to remove debug and update comment on how to clear cache. * Create LICENSE.txt Added LICENSE.txt for LGPL-2.1-or-later * Create CONTRIBUTING.md
Trying to get GitHub to properly recognize the lgpl license.
Github repository was removed. New link links to crosswire website: https://crosswire.org/bibledesktop/download.html
…157) The *4 drivers (zCom4, zText4, RawCom4, RawLD4) use 4-byte unsigned integers for file offsets. Java's int is signed, so values above 2GB appear negative, causing RandomAccessFile.seek() to fail on large modules. Changes: - DataIndex: change offset field/constructor/getter from int to long - ZVerseBackend: use & 0xFFFFFFFFL on blockNum (prevents sign-extension int->long) and change blockStart from int to long - RawBackend.getIndex(): change entryOffset from int to long with unsigned masking - RawLDBackend.getIndex(): same fix; update debug dump methods to long - ZLDBackend.getEntry(): change blockStart from int to long with unsigned masking; update debug dump method to long - DataEntry.getBlockIndex(): apply & 0xFFFFFFFFL to block offset when constructing DataIndex - gradle-wrapper: upgrade to Gradle 8.10 for Java 23+ compatibility
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description: In a nutshell
Merge the latest commits from master into develop to keep develop up-to-date with production fixes and changes landed on master.
This PR brings master’s changes into the feature branch line so CI and reviewers can validate integration before develop is advanced.
Changes included
Compare view: develop...master (Review the commit list and file changes there for details.)
Why this merge
Ensure develop contains the latest bugfixes and hotfixes applied to master.
Prevent long-lived divergence between branches that would make future merges harder.
Testing performed / required
Run the full build and test suite locally:
e.g., mvn -T 1C clean verify (or ./gradlew build) — run whichever the repo uses.
Run any repository-specific integration or manual checks that normally accompany merges from master (search/indexing, UI smoke tests, etc).
Let CI run on this PR and confirm all checks pass.
Checklist (please complete before merging)
Local build completes without errors
Unit and integration tests pass locally
CI checks on this PR are green
Resolve any merge conflicts and document resolutions in the PR description
Confirm no new or unintended API/behavioral changes were introduced
Notify maintainers/reviewers if manual verification is required for specific areas
Notes about conflicts and verification
If conflicts are present, list the conflicted files and why the resolution was chosen in this PR so reviewers can focus on the manual changes.
Call out any behavior changes that originated on master that need extra review (e.g., dependency upgrades, API tweaks, build/config changes).
Risk & rollout
Risk: low-to-medium depending on the quantity and nature of changes on master. If master contains only bugfixes, risk is low; if it contains dependency or build-system changes, risk is higher.
Rollout: after merge, run the standard develop verification steps used by the project (build, tests, smoke tests).
Suggested reviewers & approvers
@maintainers (or specific maintainers for the components touched)
The original authors of any non-trivial conflict resolutions
What I did and what I recommend next
I drafted this PR body for you to paste into the GitHub PR when you create it.
Next: create a short-lived branch from develop, merge master into it, run the build/tests, push the branch, and open a PR using this body so CI and reviewers can validate before merging into develop.
Would you like me to:
Make a shorter summary for the PR title only?
Expand the checklist with repository-specific test commands (tell me whether the project uses Maven or Gradle)?
Draft a short comment explaining conflict resolutions if you paste the conflict hunks here?
Almost out