v6.4.0

[Ghost-chu]

v6.4.0

Summary by CodeRabbit

• New Features

  • Introduced support for BitComet in the PeerBanHelper application.
  • Added a new GitHub Actions workflow for building FreeBSD packages.
  • New artifact downloading functionality in the release workflow.

• Bug Fixes

  • Improved error handling for peer retrieval in the application.

• Documentation

  • Updated README to specify how users can receive notifications for version updates.

• Chores

  • Incremented version number in project configuration files.
  • Removed outdated Unix installer options.

[Ghost-chu]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 28

🧹 Outside diff range and nitpick comments (51)

pkg/pkg/pkg-plist (1)

1-2: LGTM! Consider adding configuration and documentation files.

The pkg-plist correctly specifies the installation of the main JAR file and the startup script in appropriate locations for a FreeBSD port. This structure will allow the PeerBanHelper to function as a service on the system.

Consider the following enhancements to improve the package:

1. Add a configuration file (e.g., /usr/local/etc/peerbanhelper.conf) if the application requires one.
2. Include documentation files such as a README or man pages (e.g., /usr/local/share/doc/peerbanhelper/README.md, /usr/local/man/man1/peerbanhelper.1.gz).
3. Add cleanup instructions using @ directives (e.g., @dir /usr/local/lib/peerbanhelper) to ensure proper uninstallation.

These additions would make the package more complete and user-friendly.

pkg/pkg/post-install (3)

3-3: LGTM: Useful instruction for auto-start configuration

The echo statement provides clear instructions for enabling auto-start of peerbanhelper.

Consider adding a check for the operating system before suggesting the sysrc command, as it's specific to FreeBSD. For broader compatibility, you might want to include instructions for other common Unix-like systems.

---

4-4: LGTM: Correct usage of mkdir for creating application data directory

The use of mkdir -p to create the directory is correct and follows good practices.

Consider adding error handling and user feedback for this operation. For example:

if mkdir -p /usr/local/var/db/peerbanhelper; then
    echo "Successfully created data directory at /usr/local/var/db/peerbanhelper"
else
    echo "Failed to create data directory. Please check your permissions and try again."
    exit 1
fi

This will provide clear feedback to the user and handle potential errors.

---

1-4: Add a newline at the end of the file

It's a good practice to end shell scripts with a newline character. This follows POSIX standards and can prevent issues with certain tools.

Please add a newline at the end of the file.

src/main/resources/scripts/2e0-61ff-fe.av (3)

1-5: LGTM! Consider clarifying the script name.

The metadata section is well-structured and provides essential information about the script. Good job on explicitly defining cacheability and thread safety.

Consider updating the script name to be more specific:

-## @NAME IPV6 2e0:61ff:fe 随机后缀刷流 Peer 特征识别
+## @NAME IPv6 2e0:61ff:fe Random Suffix Flooding Peer Identification

This change makes the purpose clearer for non-Chinese speakers and maintains consistency with the English used in the rest of the metadata.

---

7-8: LGTM! Consider adding null checks.

The IP address retrieval and conversion to string look correct. However, to improve robustness:

Consider adding null checks to prevent potential NullPointerExceptions:

-ipAddress = peer.peerAddress.address;
-strIp = toString(ipAddress);
+ipAddress = peer?.peerAddress?.address;
+strIp = ipAddress ? toString(ipAddress) : "";

This change ensures that the script handles cases where peer or peerAddress might be null.

---

10-12: LGTM! Consider internationalizing the return message.

The logic for identifying the specific IPv6 pattern is correct and efficiently implemented.

Consider internationalizing the return message for better global usability:

 if(string.contains(strIp, ":2e0:61ff:fe")){
-    return "2e0:61ff:fe 特征段随机后缀 IPv6 识别";
+    return "IPv6 address identified with 2e0:61ff:fe feature segment and random suffix";
 }

This change makes the message understandable for non-Chinese speakers and maintains consistency with the English used in the metadata.

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCConfigSetResponse.java (3)

7-9: LGTM: Class declaration and annotations are well-structured.

The class name BCConfigSetResponse is descriptive and follows Java naming conventions. The use of Lombok annotations @NoArgsConstructor and @Data is appropriate for a response object, reducing boilerplate code.

Consider adding a brief Javadoc comment to describe the purpose of this class, which appears to represent a response from a BitComet configuration set operation. This would enhance code documentation and maintainability.

Example:

/**
 * Represents the response from a BitComet configuration set operation.
 * Contains error information and version details.
 */
@NoArgsConstructor
@Data
public class BCConfigSetResponse {
    // ... existing code ...
}

---

11-16: LGTM: Fields are well-defined with appropriate annotations.

The fields errorCode, errorMessage, and version are correctly defined with @SerializedName annotations to map JSON keys to Java field names. This ensures proper serialization and deserialization.

Consider refining the errorCode field:

1. If the error codes are known and finite, consider using an enum instead of a String. This would provide type safety and self-documentation.
2. If the error code is always numeric, consider using an appropriate numeric type (e.g., Integer or Long) instead of String.

Example of using an enum:

public enum ErrorCode {
    @SerializedName("0")
    SUCCESS,
    @SerializedName("1")
    INVALID_INPUT,
    // ... other error codes ...
}

public class BCConfigSetResponse {
    @SerializedName("error_code")
    private ErrorCode errorCode;
    // ... other fields ...
}

This change would make the code more robust and self-documenting, reducing the chance of errors due to incorrect string values.

---

1-17: Overall, excellent implementation of a response object.

The BCConfigSetResponse class is well-structured, concise, and effectively uses Lombok and Gson annotations to reduce boilerplate code and handle JSON serialization. It serves its purpose as a data transfer object for BitComet configuration set responses.

For future considerations:

1. If this response structure is used in multiple BitComet-related operations, consider creating a base class (e.g., BCBaseResponse) with common fields like errorCode and errorMessage. This would promote code reuse and consistency across different response types.
2. As the project evolves, maintain consistency in error handling. If you implement the suggested enum for error codes, ensure it's used consistently across all BitComet-related responses.
3. Consider adding validation logic or constraints to the fields if there are specific requirements (e.g., version format validation).

These suggestions aim to enhance maintainability and robustness as the project grows.

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCLoginResponse.java (3)

1-9: LGTM! Consider adding a brief class-level Javadoc comment.

The package declaration, imports, and class-level structure look good. The use of Lombok annotations (@NoArgsConstructor and @DaTa) effectively reduces boilerplate code.

Consider adding a brief class-level Javadoc comment to describe the purpose of this class and its role in the BitComet login process. This would enhance code documentation and maintainability.

Example:

/**
 * Represents the response structure for a BitComet login operation.
 * This class is used for JSON serialization/deserialization of login responses.
 */
@NoArgsConstructor
@Data
public class BCLoginResponse {
    // ... existing code ...
}

---

11-18: LGTM! Consider using more specific types for some fields.

The field declarations and their annotations are well-structured. The use of @SerializedName for JSON mapping is correct.

Consider using more specific types for some fields to improve type safety and clarity:

1. For errorCode, if it represents a specific set of error codes, consider using an enum.
2. For version, if it follows a specific version format (e.g., semantic versioning), consider creating a custom Version class or using a library like com.vdurmont:semver4j.

Example:

public enum ErrorCode {
    NO_ERROR, INVALID_CREDENTIALS, SERVER_ERROR;
    // ... other error codes ...
}

@SerializedName("error_code")
private ErrorCode errorCode;

@SerializedName("version")
private Version version; // Custom Version class or library

This change would provide better type safety and make the code more self-documenting.

---

1-19: LGTM! Consider adding @Builder for consistent object creation.

The overall class structure and design are well-suited for a data transfer object (DTO). The use of Lombok annotations effectively reduces boilerplate code.

To enhance consistency in object creation across your codebase, consider adding the @Builder annotation from Lombok. This would provide a fluent API for creating instances of BCLoginResponse.

Example:

import lombok.Builder;

@NoArgsConstructor
@Data
@Builder
public class BCLoginResponse {
    // ... existing code ...
}

This addition allows for creating instances like this:

BCLoginResponse response = BCLoginResponse.builder()
    .errorCode("NO_ERROR")
    .inviteToken("abc123")
    .version("1.0.0")
    .build();

This approach can make the code more readable when creating instances with multiple fields.

pkg/pkg/MANIFEST (1)

17-20: Specify the exact BSD license version

While it's good that the license information is provided, the BSD license comes in several variants (e.g., 2-clause, 3-clause). To avoid any ambiguity, it's recommended to specify the exact BSD license version being used.

Consider updating the license information to include the specific BSD license version, for example:

 "licenses": [
-    "BSD"
+    "BSD-3-Clause"
 ]

Replace "BSD-3-Clause" with the appropriate version if it's different.

pkg/synopkg/PeerBanHelperPackage/INFO.sh (1)

12-17: Consider addressing unused variables flagged by static analysis.

The static analysis tool has flagged several variables as potentially unused:

• thirdparty
• dsmappname
• install_dep_packages
• arch

While these are not directly related to the changes in this PR, addressing them could improve the overall quality of the script.

Consider the following actions:

1. Verify if these variables are used elsewhere in the build process or package metadata.
2. If they are intentionally set for external use, add comments explaining their purpose or export them explicitly.
3. If they are truly unused, consider removing them to keep the script clean and maintainable.

#!/bin/bash
# Verify if these variables are used in other files
rg --type sh 'thirdparty|dsmappname|install_dep_packages|arch' .

This suggestion is for future improvement and doesn't need to be addressed in this PR.

🧰 Tools

🪛 Shellcheck

[warning] 12-12: thirdparty appears unused. Verify use (or export if used externally).

(SC2034)

---

[warning] 14-14: dsmappname appears unused. Verify use (or export if used externally).

(SC2034)

---

[warning] 15-15: install_dep_packages appears unused. Verify use (or export if used externally).

(SC2034)

---

[warning] 17-17: arch appears unused. Verify use (or export if used externally).

(SC2034)

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCIpFilterResponse.java (2)

7-14: LGTM: Well-structured response class with appropriate annotations.

The BCIpFilterResponse class is well-defined with proper use of Lombok and GSON annotations. This reduces boilerplate code and ensures correct JSON mapping.

Consider adding a brief Javadoc comment to describe the purpose of this class, which would enhance code documentation:

/**
 * Represents a response containing IP filter configuration for BitComet.
 */
@NoArgsConstructor
@Data
public class BCIpFilterResponse {
    // ... existing code ...
}

---

16-25: LGTM: Well-structured DTO class with appropriate annotations.

The IpFilterConfigDTO nested static class is well-defined with proper use of Lombok and GSON annotations. This encapsulates related data effectively and ensures correct JSON mapping.

Consider the following minor improvements:

1. Add a brief Javadoc comment to describe the purpose of this DTO class:

/**
 * Data Transfer Object representing IP filter configuration details.
 */
@NoArgsConstructor
@Data
public static class IpFilterConfigDTO {
    // ... existing code ...
}

2. Consider using primitive types for the boolean fields if null values are not expected:

@SerializedName("enable_ip_filter")
private boolean enableIpFilter;
@SerializedName("enable_whitelist_mode")
private boolean enableWhitelistMode;

This change would prevent potential null pointer exceptions and make the intent clearer. However, if null values are possible in the JSON response, keep the current Boolean type.

pkg/pkg/work-dir/usr/local/etc/rc.d/peerbanhelper (1)

21-23: LGTM: Command setup and execution are correctly implemented.

The command setup and execution are well-implemented using the daemon command and run_rc_command function. This follows best practices for FreeBSD rc scripts.

For improved readability, consider breaking the command_args line into multiple lines:

-command_args="-f -p /var/run/${name}.pid -u ${peerbanhelper_user} ${peerbanhelper_command}"
+command_args="-f -p /var/run/${name}.pid \
+              -u ${peerbanhelper_user} \
+              ${peerbanhelper_command}"

This change doesn't affect functionality but makes the command structure easier to read and modify if needed.

.github/workflows/build_pkg.yml (2)

23-33: LGTM: FreeBSD package build step is well-structured.

The FreeBSD package build step is correctly implemented using the vmactions/freebsd-vm action. It properly sets up the directory structure, copies the JAR file, and creates the package.

Consider adding a step to verify the contents of the package after creation. You can add this command after the pkg create line:

pkg info -l pkg/peerbanhelper-${{ env.PBH_VERSION }}.pkg

This will list the contents of the package, providing an additional verification step.

---

1-39: Overall, the workflow is well-structured and fit for purpose.

This GitHub Actions workflow for building a FreeBSD package is logically organized and covers all necessary steps. It effectively utilizes both GitHub-provided and community actions to achieve its goal.

Key strengths:

1. Proper use of reusable workflow structure.
2. Effective integration of FreeBSD-specific build steps.
3. Correct artifact handling for both input (Maven distribution) and output (FreeBSD package).

Areas for consideration:

1. Pinning versions for all external actions to ensure reproducibility.
2. Adding verification steps to confirm the package contents.
3. Implementing best practices for shell script sections, such as proper quoting.

These minor improvements will enhance the robustness and maintainability of the workflow.

Consider adding a manual trigger (workflow_dispatch) to allow for ad-hoc builds, which can be useful for testing or one-off package generation:

on:
  workflow_call:
  workflow_dispatch:

This addition would provide more flexibility in using this workflow.

🧰 Tools

🪛 actionlint

17-17: shellcheck reported issue in this script: SC2086:info:2:43: Double quote to prevent globbing and word splitting

(shellcheck)

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/BCEndpoint.java (1)

1-35: Consider adding Javadoc comments for improved documentation.

While the code is well-structured and self-explanatory, adding Javadoc comments would further enhance its maintainability and usability. Consider adding:

1. A class-level Javadoc comment explaining the purpose of the BCEndpoint enum.
2. A brief Javadoc comment for the getEndpoint() method.

Here's an example of how you could add these comments:

/**
 * Represents the various API endpoints for the BitComet downloader.
 * This enum provides a centralized and type-safe way to manage and access
 * the different API endpoints used in the application.
 */
public enum BCEndpoint {
    // ... (enum constants)

    /**
     * Returns the string representation of the API endpoint.
     *
     * @return the API endpoint as a string
     */
    public String getEndpoint() {
        return endpoint;
    }
}

These comments will provide valuable context for developers working with this enum in the future.

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCTaskListResponse.java (3)

9-16: LGTM! Consider adding @AllArgsConstructor.

The BCTaskListResponse class is well-structured and uses appropriate annotations. The use of Lombok's @Data and @NoArgsConstructor is good for reducing boilerplate code.

Consider adding @AllArgsConstructor to provide a constructor with all fields, which can be useful for testing or when you need to create instances with all fields set:

 @NoArgsConstructor
+@AllArgsConstructor
 @Data
 public class BCTaskListResponse {
     // ... existing code ...
 }

---

18-49: LGTM! Consider type refinements and null safety.

The TasksDTO class is well-structured and uses appropriate annotations. Here are some suggestions for improvement:

1. Type refinements:

   • Consider using enum for type and status fields if the possible values are known and limited.
   • For leftTime, consider using a more specific type like Duration or Long (if it represents seconds/milliseconds).

2. Null safety:

   • Add @Nullable annotations to fields that can be null in the API response.
   • For non-nullable fields, consider using @NonNull to enforce null checks.

Here's an example of how you might implement these suggestions:

 @NoArgsConstructor
 @Data
 public static class TasksDTO {
     @SerializedName("task_id")
+    @NonNull
     private Long taskId;
     @SerializedName("task_guid")
+    @NonNull
     private String taskGuid;
     @SerializedName("type")
-    private String type;
+    @NonNull
+    private TaskType type;
     @SerializedName("task_name")
+    @NonNull
     private String taskName;
     @SerializedName("status")
-    private String status;
+    @NonNull
+    private TaskStatus status;
     @SerializedName("total_size")
+    @NonNull
     private Long totalSize;
     @SerializedName("selected_size")
+    @NonNull
     private Long selectedSize;
     @SerializedName("selected_downloaded_size")
+    @NonNull
     private Long selectedDownloadedSize;
     @SerializedName("download_rate")
+    @NonNull
     private Long downloadRate;
     @SerializedName("upload_rate")
+    @NonNull
     private Long uploadRate;
     @SerializedName("error_code")
+    @Nullable
     private String errorCode;
     @SerializedName("error_message")
+    @Nullable
     private String errorMessage;
     @SerializedName("permillage")
+    @NonNull
     private Long permillage;
     @SerializedName("left_time")
-    private String leftTime;
+    @NonNull
+    private Duration leftTime;
 }

+public enum TaskType {
+    // Add possible task types here
+}

+public enum TaskStatus {
+    // Add possible task statuses here
+}

Note: Ensure to import the necessary classes (Duration, NonNull, Nullable) and define the enums with appropriate values based on the BitComet API documentation.

---

1-50: Well-structured response object for BitComet API integration.

This file defines a clear and concise structure for handling responses from the BitComet task list API. The use of Lombok and Gson annotations reduces boilerplate code and ensures proper JSON serialization/deserialization. The nested TasksDTO class effectively encapsulates individual task details.

While the current implementation is functional, consider implementing the suggested improvements to enhance type safety, null handling, and overall robustness of the code.

As this class seems to be part of a larger BitComet API integration, ensure that:

1. There's proper error handling and logging when deserializing API responses.
2. The integration is well-documented, especially regarding the meaning and possible values of each field.
3. Unit tests are in place to verify correct parsing of various API response scenarios.

webui/src/components/forms/bitcomet.vue (2)

1-10: Endpoint input field looks good, but consider adding a placeholder.

The endpoint input field is well-structured with proper validation rules and internationalization. However, adding a placeholder could improve user experience.

Consider adding a placeholder to the input field:

- <a-input v-model="config.endpoint" allow-clear></a-input>
+ <a-input v-model="config.endpoint" allow-clear :placeholder="t('page.dashboard.editModal.placeholder.endpoint')"></a-input>

---

24-44: Toggle switches are properly implemented, but consider grouping related options.

The toggle switches for increment ban, SSL verification, and ignore private settings are correctly implemented with proper labeling and descriptions. However, consider grouping related options for better organization.

Consider wrapping related options in a fieldset or a custom component for better visual grouping:

<fieldset>
  <legend>{{ t('page.dashboard.editModal.label.securitySettings') }}</legend>
  <!-- Place verifySsl and ignorePrivate switches here -->
</fieldset>

src/main/java/com/ghostchu/peerbanhelper/downloader/AbstractDownloader.java (1)

43-43: Approve change with suggestion for improvement

The modification to return a DownloaderLoginResult instead of rethrowing the exception provides a consistent return type for all scenarios, which can simplify error handling for callers. However, consider preserving more error information to aid in debugging.

Consider modifying the DownloaderLoginResult class to include an optional Throwable field. This would allow you to preserve the full exception information while maintaining the new return structure. You could then update this line as follows:

return new DownloaderLoginResult(DownloaderLoginResult.Status.EXCEPTION, new TranslationComponent(e.getMessage()), e);

This change would require updating the DownloaderLoginResult class and potentially its usage elsewhere in the codebase.

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCTaskPeersResponse.java (2)

1-22: LGTM! Consider adding documentation.

The package declaration, imports, and main class structure are well-organized. The use of Lombok annotations (@NoArgsConstructor and @Data) effectively reduces boilerplate code, enhancing maintainability. The Gson @SerializedName annotations are correctly applied for JSON mapping.

Consider adding Javadoc comments to the class and its fields to improve code documentation and maintainability. For example:

/**
 * Represents a response from the BitComet task peers API.
 */
@NoArgsConstructor
@Data
public class BCTaskPeersResponse {
    /**
     * The error code returned by the API, if any.
     */
    @SerializedName("error_code")
    private String errorCode;

    // Add similar comments for other fields
}

---

1-104: Overall good structure, with room for improvement in types and documentation.

The BCTaskPeersResponse class and its inner classes are well-structured and make good use of Lombok and Gson annotations. However, there are several areas where the code could be improved:

1. Add Javadoc comments to all classes and fields to improve documentation.

2. Reconsider the types of some fields:

   • Use Integer instead of Long for count fields in PeerCountDTO where appropriate.
   • Use Duration or Long instead of String for the leftTime field in TaskDTO.
   • Use Double or Long instead of String for progress, dlSpeed, and upSpeed in PeersDTO.
   • Consider using an EnumSet or custom class for the flag field in PeersDTO.

3. Implement custom Gson TypeAdapters for any non-standard types you introduce (e.g., Duration, EnumSet).

These changes will improve the type safety, efficiency, and maintainability of the code. Please review the suggestions in the individual comments and apply them as appropriate.

webui/src/views/oobe/components/addDownloader.vue (1)

13-26: Improved UI for downloader type selection

The change from <a-radio-group> to <a-select> enhances the user interface by providing a more scalable solution for selecting downloader types. The addition of BitComet as an option expands functionality, while maintaining the disabled state for Transmission preserves existing behavior.

Consider adding a placeholder text to the select component to improve user guidance. You can add it like this:

 <a-select
   v-model="config.downloaderConfig.config.type"
   style="width: 10em"
   :trigger-props="{ autoFitPopupMinWidth: true }"
+  :placeholder="t('page.dashboard.editModal.selectDownloader')"
 >

Don't forget to add the corresponding translation key in your localization files.

webui/src/api/model/downloader.ts (1)

259-268: LGTM: Addition of bitCometConfig interface

The new bitCometConfig interface is well-structured and consistent with other client configurations. It includes all necessary properties for configuring a BitComet client.

Consider updating the downloaderConfig type to include the new bitCometConfig. Apply this diff to line 252:

export type downloaderConfig =
  | qBittorrentConfig
  | qBittorrentEEConfig
  | transmissionConfig
  | biglybtConfig
  | delugeConfig
+ | bitCometConfig

This ensures that the bitCometConfig can be used wherever downloaderConfig is expected.

webui/src/views/dashboard/components/peerListModal.vue (1)

23-23: Approved: Improved readability of peer addresses

The addition of white-space: nowrap to the a-typography-text style ensures that the IP address and port are displayed on a single line, improving readability and preventing potential misinterpretation of the address.

Consider adding a max-width property and text-overflow: ellipsis to handle cases where the container width might not be sufficient:

- <a-typography-text copyable code style="white-space: nowrap">
+ <a-typography-text copyable code style="white-space: nowrap; max-width: 100%; overflow: hidden; text-overflow: ellipsis;">

This change will ensure that the text is truncated with an ellipsis if it exceeds the available width, preventing any potential layout issues.

webui/src/views/dashboard/components/editDownloaderModal.vue (2)

14-27: LGTM! Consider adding a placeholder for better UX.

The change from radio buttons to a dropdown is a good UI improvement, especially as it allows for easier addition of new client types (like BitComet) without cluttering the interface. The disabled state and tooltip for Transmission are correctly preserved.

Consider adding a placeholder to the select component for better user experience. You can do this by adding the placeholder prop:

 <a-select
   v-model="form.config.type"
   style="width: 10em"
   :trigger-props="{ autoFitPopupMinWidth: true }"
+  placeholder="Select client type"
 >

---

Missing 'export default' statement in BitComet form component.

The bitcomet.vue file is missing the export default statement, which is required for the Vue component to function correctly.

• File: webui/src/components/forms/bitcomet.vue

🔗 Analysis chain

Line range hint 1-143: Verify BitComet form component implementation.

The BitComet client type has been consistently added throughout this file. However, it's important to ensure that the corresponding form component (@/components/forms/bitcomet.vue) exists and is implemented correctly.

Please run the following script to verify the existence and basic structure of the BitComet form component:

---

Please run the following script to locate and verify the BitComet form component:

---

Please run the following script to identify which parts of the BitComet form component are missing:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the existence and basic structure of the BitComet form component.

# Test 1: Check if the file exists
if fd -t f "bitcomet.vue" "src/components/forms"; then
    echo "BitComet form component file found."
else
    echo "Error: BitComet form component file not found."
    exit 1
fi

# Test 2: Check for basic Vue component structure
if rg -q "<template>" "src/components/forms/bitcomet.vue" && \
   rg -q "<script" "src/components/forms/bitcomet.vue" && \
   rg -q "export default" "src/components/forms/bitcomet.vue"; then
    echo "BitComet form component has basic Vue structure."
else
    echo "Warning: BitComet form component may be missing basic Vue structure."
fi

# Test 3: Check for common form elements
if rg -q "<a-form-item" "src/components/forms/bitcomet.vue" && \
   rg -q "<a-input" "src/components/forms/bitcomet.vue"; then
    echo "BitComet form component contains common form elements."
else
    echo "Warning: BitComet form component may be missing common form elements."
fi

Length of output: 263

---

Script:

# 
#!/bin/bash
# Description: Locate and verify the existence and basic structure of the BitComet form component.

# Test 1: Locate the bitcomet.vue file anywhere in the repository
file_path=$(fd -t f "bitcomet.vue")
if [ -z "$file_path" ]; then
    echo "Error: BitComet form component file not found in the repository."
    exit 1
else
    echo "BitComet form component file found at: $file_path"
fi

# Test 2: Check for basic Vue component structure
if rg -q "<template>" "$file_path" && \
   rg -q "<script" "$file_path" && \
   rg -q "export default" "$file_path"; then
    echo "BitComet form component has basic Vue structure."
else
    echo "Warning: BitComet form component may be missing basic Vue structure."
fi

# Test 3: Check for common form elements
if rg -q "<a-form-item" "$file_path" && \
   rg -q "<a-input" "$file_path"; then
    echo "BitComet form component contains common form elements."
else
    echo "Warning: BitComet form component may be missing common form elements."
fi

Length of output: 867

---

Script:

# 
#!/bin/bash
# Description: Identify missing parts of the BitComet form component's basic Vue structure.

file_path=$(fd -t f "bitcomet.vue")
if [ -z "$file_path" ]; then
    echo "Error: BitComet form component file not found in the repository."
    exit 1
else
    echo "BitComet form component file found at: $file_path"
fi

# Check for <template> tag
if rg -q "<template>" "$file_path"; then
    echo "<template> tag is present."
else
    echo "Warning: <template> tag is missing."
fi

# Check for <script> tag
if rg -q "<script" "$file_path"; then
    echo "<script> tag is present."
else
    echo "Warning: <script> tag is missing."
fi

# Check for 'export default' statement
if rg -q "export default" "$file_path"; then
    echo "'export default' statement is present."
else
    echo "Warning: 'export default' statement is missing."
fi

Length of output: 712

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCTaskTorrentResponse.java (4)

27-62: LGTM: TaskDetailDTO structure is well-defined. Consider adding documentation.

The TaskDetailDTO class is well-structured with appropriate use of annotations and field types. The fields cover comprehensive details of a torrent task.

Consider adding Javadoc comments to describe the purpose of this DTO and any non-obvious fields (e.g., infohash_v2, ltseed_upload_size) to improve code maintainability.

---

119-130: LGTM: TaskSummaryDTO structure is good. Consider refining the tags field.

The TaskSummaryDTO class is well-structured overall. The use of List<Boolean> for downloadedPieces is a good choice for representing a bitfield of downloaded pieces.

Consider changing the tags field to a collection type if it's meant to represent multiple tags:

-    private String tags;
+    private List<String> tags;

This change would make it easier to work with multiple tags without needing to parse a string.

---

132-164: LGTM: TaskDTO structure is well-defined. Consider refining the leftTime field.

The TaskDTO class is well-structured with appropriate use of Long for numeric fields. This ensures that large values can be handled correctly.

Consider changing the leftTime field to a more appropriate time-based type:

-    private String leftTime;
+    private Duration leftTime;

This change would make it easier to perform time-based calculations and comparisons in your application logic.

---

1-9: Consider documenting the use of multiple JSON libraries.

The file imports annotations from both Jackson and Gson libraries. While this provides flexibility, it may lead to confusion or maintenance issues in the future.

Consider adding a comment at the top of the file explaining why both libraries are used. For example:

/**
 * This class uses annotations from both Jackson and Gson to support multiple JSON processing libraries.
 * This approach is taken to [insert reason here, e.g., "maintain compatibility with different parts of the system"].
 */

This documentation will help future developers understand the design decision and maintain consistency across the project.

src/main/java/com/ghostchu/peerbanhelper/text/Lang.java (1)

349-349: LGTM! Consider adding documentation for new constants.

The new constants for BitComet (BC) downloader operations have been added correctly and follow the existing naming convention. They integrate well with the existing enum structure and likely correspond to new functionality or error handling implemented elsewhere in the codebase.

Consider adding Javadoc comments for these new constants to explain their specific use cases or the scenarios they represent. This would improve code maintainability and make it easier for other developers to understand when and how these constants are used.

src/main/java/com/ghostchu/peerbanhelper/module/impl/rule/ExpressionRule.java (2)

333-338: LGTM: Version file management implemented

The implementation of version file management is a good addition. It ensures proper tracking of script versions and optimizes the initialization process.

Consider using a constant for the version file name (e.g., private static final String VERSION_FILE_NAME = "version";) to improve maintainability.

---

347-347: LGTM: Preserving existing script files

The addition of this condition prevents overwriting existing script files, which is good for preserving user modifications.

Consider implementing a more sophisticated update mechanism that allows updating built-in scripts while preserving user modifications. This could involve comparing file contents or using a separate flag for user-modified scripts.

src/main/resources/lang/zh_cn/messages.yml (1)

374-382: New BitComet-related messages look good, but consider adding error codes.

The new messages for BitComet integration are clear and informative. However, to improve troubleshooting, consider adding unique error codes to each message. This would help users and support staff quickly identify and reference specific issues.

For example:

DOWNLOADER_BC_LOGIN_FAILED: "[BC001] 登录到 {} 失败：{} - {}: {}"
DOWNLOADER_BC_FAILED_REQUEST_TORRENT_LIST: "[BC002] 请求 Torrents 列表失败 - {} - {}"

This approach would make it easier to document and reference specific errors in user guides or support tickets.

🧰 Tools

🪛 yamllint

[error] 382-382: no new line character at the end of file

(new-line-at-end-of-file)

src/main/resources/lang/messages_fallback.yml (1)

383-383: Add a newline at the end of the file

To improve file consistency and adhere to common coding standards, please add a newline at the end of the file.

Apply this change:

 DOWNLOADER_BC_CONFIG_IP_FILTER_FAILED: "BitComet IpFilter 配置自动修正失败"
+

🧰 Tools

🪛 yamllint

[error] 383-383: no new line character at the end of file

(new-line-at-end-of-file)

pom.xml (1)

Line range hint 670-685: Consider removing or explaining commented-out dependency.

There's a commented-out dependency for com.pixelduke:transit. While it's common to keep commented dependencies in pom.xml for future reference, it's generally a good practice to either:

1. Remove the commented-out code if it's no longer needed.
2. Add a comment explaining why this dependency is kept in a commented state and under what circumstances it might be reintroduced.

This helps maintain a clean and understandable pom.xml file.

src/main/resources/lang/en_us/messages.yml (1)

377-384: LGTM: BitComet messages added correctly.

The new messages for BitComet downloader functionality are consistent with the existing style and provide clear error messages and status updates. They align well with similar messages for other downloaders, maintaining consistency throughout the file.

Minor issue: Missing new line at end of file.

According to the static analysis hint, there's no new line character at the end of the file. This is a minor issue but should be addressed for consistency and to follow YAML best practices.

To fix this, simply add a new line after the last message:

 DOWNLOADER_BC_CONFIG_IP_FILTER_SUCCESS: "BitComet IpFilter configuration autofix success."
 DOWNLOADER_BC_CONFIG_IP_FILTER_FAILED: "BitComet IpFilter configuration autofix failed."
+

🧰 Tools

🪛 yamllint

[error] 384-384: no new line character at the end of file

(new-line-at-end-of-file)

src/main/java/com/ghostchu/peerbanhelper/PeerBanHelperServer.java (1)

697-702: Improved peer collection, but consider more specific error handling.

The changes in the collectPeers method improve code readability by introducing a new variable p for storing peers. The added error logging on line 702 is beneficial for debugging purposes. However, there's a potential area for improvement:

1. On line 701, catching a general Exception might be too broad. Consider catching more specific exceptions to handle different error scenarios appropriately.

Consider refining the error handling by catching specific exceptions. For example:

 try {
     parallelReqRestrict.acquire();
     var p =  downloader.getPeers(torrent);
     peers.put(torrent,p);
 } catch (InterruptedException e) {
     Thread.currentThread().interrupt();
-}  catch (Exception e) {
-    log.error("Unable to retrieve peers", e);
+} catch (IOException e) {
+    log.error("Unable to retrieve peers due to I/O error", e);
+} catch (DownloaderException e) {
+    log.error("Unable to retrieve peers due to downloader error", e);
+} catch (Exception e) {
+    log.error("Unexpected error while retrieving peers", e);
 } finally {
     parallelReqRestrict.release();
 }

This approach allows for more granular error handling and logging, which can be helpful for troubleshooting specific issues.

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/crypto/BCAESTool.java (1)

53-53: Remove irrelevant comment about HTTP client.

The comment about using an HTTP client seems misplaced, as this method does not perform any HTTP requests. Consider removing it to avoid confusion.

Apply this diff:

-// Use an HTTP client like OkHttp or Apache HttpClient for the POST request

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/BitComet.java (4)

65-65: Commented Out Accept-Encoding Header

On line 65, the Accept-Encoding header is commented out. Including this header allows the client to accept compressed responses, potentially improving network efficiency.

If there is no specific reason for commenting it out, consider uncommenting it:

- //.defaultHeader("Accept-Encoding", "gzip,deflate")
+ .defaultHeader("Accept-Encoding", "gzip,deflate")

---

332-335: Empty Override of close() Method

The close() method is overridden but left empty (lines 332-335). If there are no resources to clean up, it's unnecessary to implement AutoCloseable.

Either remove the close() method if it's not needed or provide a comment explaining why it's intentionally left empty.

- @Override
- public void close() throws Exception {
- 
- }
+ // No resources to close; method intentionally left empty.

---

293-298: Simplify Conditional Logic in setBanList()

The conditional statement in setBanList() (lines 293-298) is complex and may affect readability.

Consider simplifying the condition or breaking it into smaller logical components with explanatory variables.

boolean shouldIncrementBan = removed != null && removed.isEmpty() && added != null && config.isIncrementBan() && !applyFullList;

if (shouldIncrementBan) {
    setBanListIncrement(added);
} else {
    setBanListFull(fullList);
}

---

106-106: Method Name Does Not Follow Convention

The method login0() (line 106) uses a numerical suffix in its name, which may not be descriptive.

Consider renaming the method to better reflect its purpose, such as performLogin() or authenticate().

- public DownloaderLoginResult login0() throws Exception {
+ public DownloaderLoginResult authenticate() throws Exception {

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 304af0a and 9acecdd.

⛔ Files ignored due to path filters (1)

• webui/pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (40)

• .github/workflows/build_pkg.yml (1 hunks)
• .github/workflows/jvm-ci.yml (2 hunks)
• .github/workflows/jvm-release.yml (3 hunks)
• README.md (2 hunks)
• install4j/project.install4j (0 hunks)
• pkg/pkg/MANIFEST (1 hunks)
• pkg/pkg/pkg-plist (1 hunks)
• pkg/pkg/post-install (1 hunks)
• pkg/pkg/work-dir/usr/local/etc/rc.d/peerbanhelper (1 hunks)
• pkg/synopkg/PeerBanHelperPackage/INFO.sh (1 hunks)
• pom.xml (3 hunks)
• src/main/java/com/ghostchu/peerbanhelper/PeerBanHelperServer.java (5 hunks)
• src/main/java/com/ghostchu/peerbanhelper/downloader/AbstractDownloader.java (2 hunks)
• src/main/java/com/ghostchu/peerbanhelper/downloader/Downloader.java (1 hunks)
• src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/BCEndpoint.java (1 hunks)
• src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/BitComet.java (1 hunks)
• src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/crypto/BCAESTool.java (1 hunks)
• src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCConfigSetResponse.java (1 hunks)
• src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCDeviceTokenResult.java (1 hunks)
• src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCIpFilterResponse.java (1 hunks)
• src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCLoginResponse.java (1 hunks)
• src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCTaskListResponse.java (1 hunks)
• src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCTaskPeersResponse.java (1 hunks)
• src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCTaskTorrentResponse.java (1 hunks)
• src/main/java/com/ghostchu/peerbanhelper/module/impl/rule/ExpressionRule.java (3 hunks)
• src/main/java/com/ghostchu/peerbanhelper/module/impl/webapi/PBHDownloaderController.java (1 hunks)
• src/main/java/com/ghostchu/peerbanhelper/text/Lang.java (1 hunks)
• src/main/resources/lang/en_us/messages.yml (1 hunks)
• src/main/resources/lang/messages_fallback.yml (1 hunks)
• src/main/resources/lang/zh_cn/messages.yml (1 hunks)
• src/main/resources/scripts/2e0-61ff-fe.av (1 hunks)
• webui/package.json (3 hunks)
• webui/src/api/model/downloader.ts (2 hunks)
• webui/src/components/forms/bitcomet.vue (1 hunks)
• webui/src/components/plusModal.vue (1 hunks)
• webui/src/locale/en-US/plus.ts (1 hunks)
• webui/src/locale/zh-CN/plus.ts (1 hunks)
• webui/src/views/dashboard/components/editDownloaderModal.vue (3 hunks)
• webui/src/views/dashboard/components/peerListModal.vue (2 hunks)
• webui/src/views/oobe/components/addDownloader.vue (2 hunks)

💤 Files with no reviewable changes (1)

• install4j/project.install4j

✅ Files skipped from review due to trivial changes (3)

• src/main/java/com/ghostchu/peerbanhelper/downloader/Downloader.java
• webui/src/locale/en-US/plus.ts
• webui/src/locale/zh-CN/plus.ts

🧰 Additional context used

🪛 actionlint

.github/workflows/build_pkg.yml

17-17: shellcheck reported issue in this script: SC2086:info:2:43: Double quote to prevent globbing and word splitting

(shellcheck)

🪛 Shellcheck

pkg/synopkg/PeerBanHelperPackage/INFO.sh

[warning] 11-11: maintainer_url appears unused. Verify use (or export if used externally).

(SC2034)

---

[warning] 12-12: thirdparty appears unused. Verify use (or export if used externally).

(SC2034)

---

[warning] 14-14: dsmappname appears unused. Verify use (or export if used externally).

(SC2034)

---

[warning] 15-15: install_dep_packages appears unused. Verify use (or export if used externally).

(SC2034)

---

[warning] 17-17: arch appears unused. Verify use (or export if used externally).

(SC2034)

---

[warning] 18-18: description appears unused. Verify use (or export if used externally).

(SC2034)

🪛 yamllint

src/main/resources/lang/en_us/messages.yml

[error] 384-384: no new line character at the end of file

(new-line-at-end-of-file)

src/main/resources/lang/messages_fallback.yml

[error] 383-383: no new line character at the end of file

(new-line-at-end-of-file)

src/main/resources/lang/zh_cn/messages.yml

[error] 382-382: no new line character at the end of file

(new-line-at-end-of-file)

🔇 Additional comments (56)

pkg/pkg/post-install (1)

1-1: LGTM: Appropriate shebang for shell script

The shebang #!/bin/sh is correct and ensures maximum compatibility across different Unix-like systems.

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCConfigSetResponse.java (1)

1-5: LGTM: Package declaration and imports are appropriate.

The package name follows Java naming conventions, and the imports are relevant to the class's functionality. Good use of Lombok for reducing boilerplate code and Gson for JSON serialization.

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCLoginResponse.java (1)

1-19: Great addition! Here's a summary of suggestions for further improvement.

This new BCLoginResponse class is well-structured and effectively uses Lombok and Gson annotations. It serves its purpose as a DTO for BitComet login responses.

To further enhance the code quality, consider implementing the following suggestions:

1. Add a class-level Javadoc comment to describe the purpose and usage of this class.
2. Use more specific types for errorCode and version fields if applicable.
3. Add the @Builder annotation to provide a consistent way of creating instances.

These changes will improve documentation, type safety, and ease of use. Great job on this addition to the project!

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCDeviceTokenResult.java (2)

8-10: Class declaration and annotations look good.

The use of Lombok annotations @NoArgsConstructor and @Data is appropriate here. These annotations will generate a no-args constructor, getters, setters, toString(), equals(), and hashCode() methods, reducing boilerplate code.

---

12-19: Field declarations are well-structured.

The use of @SerializedName annotations correctly maps the Java field names to their JSON counterparts. The naming conventions are consistent, with camelCase for Java fields and snake_case for JSON properties.

pkg/pkg/MANIFEST (5)

9-14: Dependencies section looks good

The dependency on openjdk21 version 21.0 is clearly specified. This is a good practice as it ensures reproducibility and avoids potential issues with incompatible versions.

---

15-16: Categories and prefix are appropriate

The categorization under "net" is suitable for a tool related to the BitTorrent network. The installation prefix "/usr/local" is a standard and appropriate location for user-installed software on Unix-like systems.

---

1-24: Well-structured and formatted manifest

The overall structure and formatting of the manifest file are excellent. The JSON is well-formed, properly indented, and includes all the necessary fields for a package manifest. This makes the file easy to read and maintain.

---

1-24: Overall, a well-constructed manifest with minor improvements needed

This manifest file for the peerbanhelper package is comprehensive and well-structured. It provides all the necessary information for package management. However, there are a few minor points to address:

1. Replace the "" placeholder with the actual version number (6.4.0).
2. Verify the maintainer's email address (111.com domain).
3. Specify the exact BSD license version being used.
4. Ensure the existence and correctness of the post-install script.

Once these points are addressed, the manifest will be in excellent shape for the v6.4.0 release.

---

21-23: Verify the post-install script

A post-install script is specified, which is good for performing any necessary setup after installation. However, the content of this script is not visible in the manifest.

Please ensure that:

1. The "post-install" script exists in the package.
2. The script performs the necessary post-installation tasks correctly.

You can use the following command to locate and display the content of the post-install script:

#!/bin/bash
# Find and display the content of the post-install script
fd -t f post-install --exec cat {}

pkg/synopkg/PeerBanHelperPackage/INFO.sh (1)

18-18: Approve update to description with a minor consideration.

The update to the description correctly adds BitComet to the list of supported BitTorrent clients, which is consistent with the version update to 6.4.0. This change effectively communicates the expanded compatibility of the PeerBanHelper package.

Similar to maintainer_url, the static analysis tool flags description as potentially unused. To address this:

1. Verify if this variable is used elsewhere in the build process or package metadata.
2. If it's intentionally set for external use, consider adding a comment explaining its purpose or export it explicitly.

#!/bin/bash
# Verify if description is used in other files
rg --type sh 'description=' .

Additionally, consider adding an English translation of the description as a comment, to improve accessibility for non-Chinese speaking users or contributors.

🧰 Tools

🪛 Shellcheck

[warning] 18-18: description appears unused. Verify use (or export if used externally).

(SC2034)

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCIpFilterResponse.java (2)

3-5: LGTM: Import statements are appropriate and concise.

The import statements are correctly used for GSON annotations and Lombok annotations, which are utilized in the class definitions. There are no unused imports.

---

1-26: Overall, excellent implementation of DTO classes for BitComet IP filter response.

The BCIpFilterResponse.java file is well-structured and efficiently implements DTO classes for handling BitComet IP filter responses. The use of Lombok and GSON annotations is appropriate and helps in reducing boilerplate code while ensuring correct JSON mapping.

Key strengths:

1. Proper use of nested static class for related data
2. Effective use of Lombok annotations for code reduction
3. Correct application of GSON annotations for JSON serialization/deserialization

The suggested minor improvements in documentation and potential use of primitive types for boolean fields would further enhance the code quality, but these are not critical issues.

pkg/pkg/work-dir/usr/local/etc/rc.d/peerbanhelper (1)

1-7: LGTM: Script header and dependencies are correctly set up.

The script header follows the standard format for FreeBSD rc scripts. It correctly defines the service name, dependencies, and sources the necessary rc.subr file.

.github/workflows/build_pkg.yml (2)

1-7: LGTM: Workflow setup is appropriate.

The workflow is correctly set up as a reusable workflow triggered by workflow_call. The job configuration using ubuntu-latest is suitable for the build tasks.

---

34-39: LGTM: Artifact upload step is correctly implemented.

The artifact upload step is well-configured:

• It uses the latest version of the upload-artifact action.
• The file pattern pkg/*.pkg should correctly capture the built package.

This step ensures that the built FreeBSD package is available for subsequent workflow steps or for download.

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/BCEndpoint.java (2)

1-3: LGTM: Package declaration and enum structure are well-defined.

The package name follows Java naming conventions, and the enum name BCEndpoint is concise and descriptive. The code structure is clean with appropriate spacing.

---

26-34: LGTM: Private field, constructor, and getter method are well-implemented.

The implementation follows good practices:

• The endpoint field is declared as private and final, ensuring encapsulation and immutability.
• The constructor properly initializes the endpoint field.
• The getEndpoint() method follows Java naming conventions and provides access to the endpoint value.

This structure ensures that each enum constant is associated with an immutable endpoint string and provides a clean way to access it.

webui/package.json (1)

32-32: Approve dependency updates with verification recommendation.

The updates to vue, @types/node, and vite-bundle-analyzer are minor version increments, which is a good practice for keeping dependencies up-to-date. These changes likely include bug fixes, performance improvements, or enhanced compatibility.

To ensure these updates don't introduce any unexpected behavior:

1. Run the project's test suite to check for any regressions.
2. Verify that the project builds and runs correctly with these new versions.
3. Check the changelogs of these packages to understand what has changed:
   • Vue.js: https://github.com/vuejs/core/blob/main/CHANGELOG.md
   • @types/node: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/node/CHANGELOG.md
   • vite-bundle-analyzer: https://github.com/btd/rollup-plugin-visualizer/blob/master/CHANGELOG.md

If any issues are encountered during these steps, please review and address them before merging this pull request.

Also applies to: 47-47, 63-63

.github/workflows/jvm-ci.yml (2)

66-66: LGTM: docker/build-push-action updated to v6.8.0.

Updating the docker/build-push-action to the latest minor version (v6.8.0) is a good practice. This update likely includes bug fixes and minor improvements.

To ensure there are no breaking changes or significant new features that might affect the workflow, please review the changelog for docker/build-push-action between versions v6.7.0 and v6.8.0. You can find the changelog at:

https://github.com/docker/build-push-action/releases

If there are any notable changes that might impact this workflow, please consider documenting them in a comment.

---

30-32: LGTM: New Build_PKG job added.

The addition of the Build_PKG job is consistent with the existing workflow structure and follows best practices by depending on the CI job. This ensures that packages are only built after successful CI checks.

To ensure the referenced workflow file exists, please run the following script:

✅ Verification successful

Verified: Build_PKG job correctly references .github/workflows/build_pkg.yml.

The Build_PKG job has been successfully verified to reference an existing workflow file, ensuring it functions as intended within the CI pipeline.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the existence of the build_pkg.yml workflow file

# Test: Check if the file exists
if [ -f ".github/workflows/build_pkg.yml" ]; then
    echo "build_pkg.yml file exists."
else
    echo "Error: build_pkg.yml file not found."
    exit 1
fi

Length of output: 107

webui/src/components/forms/bitcomet.vue (4)

11-16: Username and password fields are correctly implemented.

The username and password fields are properly set up with appropriate input types and clear functionality.

---

17-23: HTTP Version selection is well-implemented.

The radio group for HTTP version selection is correctly set up with proper labeling and description.

---

46-52: Script setup and model definition look good.

The script setup, imports, and model definition using defineModel are correctly implemented.

---

1-69: Overall, the BitComet configuration component is well-implemented.

The component demonstrates good use of Vue 3 features, TypeScript, and internationalization. It provides a comprehensive form for BitComet downloader configuration with appropriate input validation.

Key strengths:

1. Consistent use of internationalization throughout the component.
2. Proper implementation of form validation, especially for the endpoint URL.
3. Good use of Arco Design Vue components for a consistent UI.

Areas for potential improvement:

1. Consider adding placeholders to input fields for better user guidance.
2. Group related configuration options (e.g., security settings) for improved organization.
3. Further refine error handling in the URL validation to cover all possible scenarios.

These improvements are minor, and the component is already in a good state for production use.

webui/src/components/plusModal.vue (2)

47-49: Improved typography and readability

The change from <a-typography-text> to <a-typography-paragraph> with added styling is a good improvement. It better represents the semantic structure of the content and enhances readability.

• The max-width: 50em ensures the text doesn't stretch too wide, which is beneficial for readability on larger screens.
• The text-align: left maintains consistent alignment, which is generally preferred for longer text blocks.

These changes align well with best practices in typography and user interface design.

---

Line range hint 1-108: Summary of changes

The modifications in this file focus on improving the presentation of content within the PeerBanHelper Plus modal:

1. The typography element for the "begging" text has been updated to use a paragraph style with improved readability.
2. The support image width has been increased to 100%, which may improve visibility but should be tested across different screen sizes.

These changes enhance the user interface without altering the core functionality of the component. The code structure remains clean and follows Vue.js best practices.

Recommendations:

• Test the modal on various screen sizes to ensure the new image width doesn't cause layout issues.
• Consider implementing responsive design techniques for the image as suggested earlier.

Overall, these changes are beneficial and can be merged after addressing the image width consideration.

webui/src/views/oobe/components/addDownloader.vue (3)

65-65: New BitComet form component import added

The addition of the bitCometForm import using defineAsyncComponent is consistent with the existing pattern for other downloader types. This change supports the new BitComet option in the UI.

---

72-73: Updated formMap to include BitComet

The formMap object has been correctly updated to include the new BitComet form component. This change ensures that the appropriate form is displayed when BitComet is selected as the downloader type.

The addition of a trailing comma after the Deluge entry is a good practice for easier future additions and cleaner version control diffs.

---

Line range hint 1-96: Verify complete implementation of BitComet support

While the changes in this file correctly add UI support for BitComet, it's important to ensure that the new downloader type is fully supported throughout the application.

Please run the following script to check for BitComet support in other parts of the codebase:

This script will help identify any areas where BitComet support might need to be added or updated.

✅ Verification successful

✅ BitComet Support Fully Verified

The implementation of BitComet has been confirmed across all relevant parts of the codebase, including API models, service layers, configuration processors, backend Java files, Vue components, and documentation.

• API Models: BitComet references found in src/api/model/downloader.ts.
• Service Layer: BitComet integrations present in src/main/java/com/ghostchu/peerbanhelper/PeerBanHelperServer.java.
• Configuration Processors: Configuration adjustments detected in YAML files under src/main/resources/lang/.
• Backend Java Files: Comprehensive BitComet support in src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/BitComet.java.
• Vue Components: UI elements and form mappings for BitComet in webui/src/views/oobe/components/addDownloader.vue and related dashboard components.
• Documentation: BitComet mentioned in README.md and configuration scripts.

---

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for BitComet support in other parts of the codebase

# Test 1: Check for BitComet in API models
echo "Checking API models for BitComet:"
rg --type typescript "BitComet" src/api/model

# Test 2: Check for BitComet in service layer
echo "Checking service layer for BitComet:"
rg --type typescript "BitComet" src/service

# Test 3: Check for BitComet in configuration processors
echo "Checking configuration processors for BitComet:"
rg --type typescript "BitComet" src/config

# Test 4: Check for BitComet in documentation
echo "Checking documentation for BitComet:"
rg "BitComet" docs README.md

# Note: Adjust paths if necessary based on your project structure

Length of output: 713

---

Script:

#!/bin/bash
# Description: Enhanced check for BitComet support in the codebase

# Test 1: Check for BitComet in API models
echo "Checking API models for BitComet:"
rg "BitComet" $(fd --extension ts src/api/model)

# Test 2: Check for BitComet in service layer
echo "Checking service layer for BitComet:"
rg "BitComet" $(fd --extension ts src/service)

# Test 3: Check for BitComet in configuration processors
echo "Checking configuration processors for BitComet:"
rg "BitComet" $(fd --extension ts src/config)

# Test 4: Check for BitComet in documentation
echo "Checking documentation for BitComet:"
rg "BitComet" $(fd --extension md docs || echo "docs directory not found")

Length of output: 18721

---

Script:

#!/bin/bash
# Description: Comprehensive check for BitComet support across the entire codebase

# Test 1: Check for BitComet in TypeScript files within API models
echo "Checking TypeScript files in src/api/model for BitComet:"
rg "BitComet" $(fd --extension ts src/api/model)

# Test 2: Check for BitComet in TypeScript files within service layer
echo "Checking TypeScript files in src/service for BitComet:"
rg "BitComet" $(fd --extension ts src/service)

# Test 3: Check for BitComet in TypeScript files within configuration processors
echo "Checking TypeScript files in src/config for BitComet:"
rg "BitComet" $(fd --extension ts src/config)

# Test 4: Check for BitComet in all Markdown files within documentation
echo "Checking Markdown files in docs for BitComet:"
if fd --extension md docs > /dev/null 2>&1; then
  rg "BitComet" $(fd --extension md docs)
else
  echo "docs directory or Markdown files not found."
fi

# Test 5: Check for BitComet in Java files within the backend
echo "Checking Java files in src/main/java for BitComet:"
rg "BitComet" $(fd --extension java src/main/java)

# Test 6: Check for BitComet in Vue components
echo "Checking Vue files in webui/src/views for BitComet:"
rg "BitComet" $(fd --extension vue webui/src/views)

# Test 7: Check for BitComet in configuration and language files
echo "Checking YAML and JSON files for BitComet:"
rg "BitComet" $(fd --extension yml .) $(fd --extension json .)

Length of output: 31095

---

Script:

#!/bin/bash
# Description: Comprehensive check for BitComet support across the entire codebase with corrected search patterns

# Test 1: Check for BitComet in TypeScript files within API models
echo "Checking TypeScript files in src/api/model for BitComet:"
rg "BitComet" $(fd --extension ts src/api/model)

# Test 2: Check for BitComet in TypeScript files within service layer
echo "Checking TypeScript files in src/service for BitComet:"
rg "BitComet" $(fd --extension ts src/service)

# Test 3: Check for BitComet in TypeScript files within configuration processors
echo "Checking TypeScript files in src/config for BitComet:"
rg "BitComet" $(fd --extension ts src/config)

# Test 4: Check for BitComet in all Markdown files within documentation
echo "Checking Markdown files in docs for BitComet:"
if fd --extension md docs > /dev/null 2>&1; then
  rg "BitComet" $(fd --extension md docs)
else
  echo "docs directory or Markdown files not found."
fi

# Test 5: Check for BitComet in Java files within the backend
echo "Checking Java files in src/main/java for BitComet:"
rg "BitComet" $(fd . src/main/java --extension java)

# Test 6: Check for BitComet in Vue components
echo "Checking Vue files in webui/src/views for BitComet:"
rg "BitComet" $(fd . webui/src/views --extension vue)

# Test 7: Check for BitComet in configuration and language files
echo "Checking YAML and JSON files for BitComet:"
rg "BitComet" $(fd . --extension yml .) $(fd . --extension json .)

Length of output: 50575

webui/src/api/model/downloader.ts (2)

24-24: LGTM: Addition of BitComet to ClientTypeEnum

The addition of 'BitComet' to the ClientTypeEnum is consistent with the existing structure and naming conventions. This change appropriately extends the enum to support BitComet clients.

---

24-24: Summary: BitComet client support added

The changes in this file successfully introduce support for BitComet clients:

1. BitComet has been added to the ClientTypeEnum.
2. A new bitCometConfig interface has been defined with all necessary properties.

These additions enhance the downloader module by expanding the range of supported clients. The changes are well-integrated and consistent with the existing code structure.

To ensure the changes are properly integrated, run the following script:

This script will help verify that the BitComet changes are properly integrated and used throughout the codebase.

Also applies to: 259-268

✅ Verification successful

shell
#!/bin/bash

Description: Verify BitComet integration in the codebase

Test 1: Check if BitComet is used in other parts of the codebase

echo "Checking BitComet usage:"
rg "ClientTypeEnum.BitComet" --glob '!**/downloader.ts' --glob '*.ts'

Test 2: Verify if bitCometConfig is imported and used correctly

echo "Checking bitCometConfig usage:"
rg "bitCometConfig" --glob '!**/downloader.ts' --glob '*.ts'

Test 3: Look for any TODO comments related to BitComet integration

echo "Checking for TODO comments related to BitComet:"
rg "TODO.BitComet" --glob '.ts'

---

Verification Successful: BitComet integration is correctly confined to downloader.ts

The shell script results confirm that:

1. ClientTypeEnum.BitComet is only used in webui/src/api/model/downloader.ts.
2. bitCometConfig is exclusively defined in downloader.ts.
3. No TODO comments related to BitComet are present elsewhere in the codebase.

These findings indicate that the BitComet support has been properly integrated without impacting other parts of the codebase.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify BitComet integration in the codebase

# Test 1: Check if BitComet is used in other parts of the codebase
echo "Checking BitComet usage:"
rg --type typescript "ClientTypeEnum\.BitComet" --glob '!**/downloader.ts'

# Test 2: Verify if bitCometConfig is imported and used correctly
echo "Checking bitCometConfig usage:"
rg --type typescript "bitCometConfig" --glob '!**/downloader.ts'

# Test 3: Look for any TODO comments related to BitComet integration
echo "Checking for TODO comments related to BitComet:"
rg --type typescript "TODO.*BitComet"

Length of output: 521

---

Script:

Length of output: 98

---

Script:

#!/bin/bash
# Description: Verify BitComet integration in the codebase

# Test 1: Check if BitComet is used in other parts of the codebase
echo "Checking BitComet usage:"
rg "ClientTypeEnum\.BitComet" --glob "!**/downloader.ts" --glob "*.ts"

# Test 2: Verify if bitCometConfig is imported and used correctly
echo "Checking bitCometConfig usage:"
rg "bitCometConfig" --glob "!**/downloader.ts" --glob "*.ts"

# Test 3: Look for any TODO comments related to BitComet integration
echo "Checking for TODO comments related to BitComet:"
rg "TODO.*BitComet" --glob "*.ts"

Length of output: 538

webui/src/views/dashboard/components/peerListModal.vue (2)

118-118: Approved: Increased width for peer address column

The increase in column width from 300 to 320 pixels provides more space for the peer address, which is beneficial given the white-space: nowrap style added earlier. This change helps accommodate longer IP addresses without truncation.

To ensure this change doesn't negatively impact the overall table layout, please verify the following:

1. Check that the total width of all columns (1600px as set in the a-table style) is still appropriate.
2. Test the component with various screen sizes to ensure responsiveness is maintained.
3. Confirm that no horizontal scrolling is introduced unnecessarily on common display sizes.

You can use the browser's developer tools to inspect the rendered table and verify these aspects.

---

Line range hint 1-168: Overall assessment: Minor improvements to peer address display

The changes made to this file are focused on improving the display of peer addresses in the peer list modal. The addition of white-space: nowrap and the increase in column width work together to enhance readability and prevent potential misinterpretation of addresses.

These modifications are generally positive and should improve the user experience. The suggestions provided in the previous comments (adding max-width and text-overflow, and verifying table layout) are minor optimizations that could further refine the implementation.

No major issues or concerns were identified in this review.

webui/src/views/dashboard/components/editDownloaderModal.vue (3)

62-62: LGTM! Consistent import for BitComet form.

The import statement for the BitComet form component is correctly implemented using defineAsyncComponent for lazy loading, consistent with other form imports.

---

73-74: LGTM! Correct formMap update for BitComet.

The formMap object has been correctly updated to include the BitComet form component. The formatting change for the Deluge entry improves readability.

---

Line range hint 1-143: Summary: Well-integrated BitComet support with improved UI.

The changes in this file successfully integrate support for the BitComet client type while improving the UI by switching from radio buttons to a dropdown for client type selection. This change enhances scalability for future client additions. The BitComet form component is consistently imported and integrated into the existing structure.

Key points:

1. UI updated from radio buttons to dropdown (lines 14-27)
2. BitComet form component imported (line 62)
3. formMap updated to include BitComet (lines 73-74)

The changes are well-implemented and maintain consistency with the existing code structure and style. No apparent issues or inconsistencies are introduced by these modifications.

.github/workflows/jvm-release.yml (2)

70-73: LGTM: New artifact download step added.

The addition of this step to download the 'pkg-dist' artifact is consistent with the workflow's structure and purpose. It ensures that all necessary artifacts are available for the subsequent upload step.

---

121-121: LGTM: Docker build-push-action version updated.

The update of docker/build-push-action from v6.7.0 to v6.8.0 is consistent and follows good practices for keeping actions up-to-date.

To ensure a smooth transition, please verify if there are any breaking changes or new features in v6.8.0 that might affect our workflow:

Also applies to: 157-157

✅ Verification successful

LGTM: Docker build-push-action version updated.

The update of docker/build-push-action from v6.7.0 to v6.8.0 is consistent and follows best practices for keeping actions up-to-date. No breaking changes were found in the v6.8.0 changelog.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Fetch the changelog for docker/build-push-action
gh release view v6.8.0 --repo docker/build-push-action

Length of output: 466

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/resp/BCTaskTorrentResponse.java (2)

10-25: LGTM: Main class structure is well-defined.

The BCTaskTorrentResponse class is well-structured and uses appropriate annotations. The use of Lombok's @Data and @NoArgsConstructor reduces boilerplate code, while @SerializedName ensures proper JSON mapping. The fields cover various aspects of a BitComet task response, providing a comprehensive representation.

---

1-164: Overall assessment: Well-structured with minor improvements suggested.

The BCTaskTorrentResponse.java file is generally well-structured and provides a comprehensive representation of a BitComet torrent task response. The use of Lombok annotations reduces boilerplate code, and the nested DTO classes provide a clear organization of different aspects of the task response.

Key points:

1. Consider using more appropriate data types for numeric and time-based fields, especially in TaskStatusDTO and TaskDTO.
2. Add documentation to explain the use of multiple JSON libraries and describe non-obvious fields.
3. Consider changing the tags field in TaskSummaryDTO to a collection type if it represents multiple tags.

These improvements will enhance type safety, ease of use, and maintainability of the code.

README.md (2)

8-8: LGTM: Improved instructions for update notifications

The updated note provides more specific guidance on how users can receive version update notifications. This change enhances user experience by directing them to the exact settings they need to adjust in GitHub (Custom -> Releases, Issues, and Discussions).

---

32-32: Verify the date in the BitComet version number

The addition of BitComet to the list of compatible software is great as it expands the compatibility of PeerBanHelper. However, please verify the date in the version number (20240928). This date appears to be in the future (September 28, 2024), which is unusual for a software version. If this is correct, consider adding a note explaining why a future date is used. If it's a typo, please correct it to the intended date.

src/main/java/com/ghostchu/peerbanhelper/module/impl/rule/ExpressionRule.java (3)

62-62: LGTM: Version constant added

The addition of the VERSION constant is a good practice for managing script versions. It's correctly defined as a private static final String.

---

351-351: LGTM: Updating version file after initialization

Writing the VERSION to the version file after successful script initialization is a good practice. It ensures that the version file accurately reflects the current state of the scripts.

---

Line range hint 62-351: Overall assessment: Robust script versioning system implemented

The changes introduce a well-implemented versioning system for scripts. The additions include:

1. A VERSION constant for easy management of script versions.
2. Version file management to track the current script version.
3. Preservation of existing script files to maintain user modifications.
4. Proper updating of the version file after successful script initialization.

These changes enhance the maintainability and updatability of the script system. The suggestions provided in the review comments could further improve the implementation.

src/main/resources/lang/messages_fallback.yml (1)

376-383: New BitComet messages look good!

The newly added messages for BitComet downloader are consistent with the existing style and provide clear, informative error messages for various scenarios. They cover important aspects such as login failures, request failures, and configuration issues, which will help in troubleshooting and user communication.

🧰 Tools

🪛 yamllint

[error] 383-383: no new line character at the end of file

(new-line-at-end-of-file)

pom.xml (4)

9-9: Version update looks good.

The project version has been incremented from 6.3.0 to 6.4.0, which aligns with the PR title. This minor version update suggests new features or non-breaking changes have been introduced.

---

412-420: Build configuration improvements look good.

The added exclusions in the maven-shade-plugin configuration are beneficial:

1. They help reduce the final JAR size by removing unnecessary files.
2. They prevent potential conflicts that could arise from including multiple JAR signatures.
3. The exclusions cover common patterns like signature files (*.SF, *.DSA, *.RSA), Kotlin module files, license files, and other metadata.

These changes align with best practices for creating lean and conflict-free JAR files.

---

Line range hint 1-685: Overall, the changes look good and align with the v6.4.0 release.

The modifications to the pom.xml file are generally positive:

1. The version has been correctly updated to 6.4.0.
2. Build configuration improvements have been made to create a leaner JAR file.
3. A new cryptography dependency (BouncyCastle) has been added, potentially introducing new features.

Consider addressing the minor suggestions in the previous comments to further improve the project configuration. Great job on preparing this release!

---

663-668: New BouncyCastle dependency added.

The addition of the BouncyCastle cryptography library (bcprov-jdk18on) is noted. This suggests new cryptographic features or requirements have been introduced to the project.

However, please consider the following:

1. Verify if version 1.78.1 is the intended version, as it's not the latest release according to my knowledge.
2. It would be helpful to document the specific reason for adding this dependency, either in a comment or in the project documentation.

To check for the latest version of BouncyCastle, you can run:

✅ Verification successful

BouncyCastle Dependency Version Verified.

The BouncyCastle cryptography library (bcprov-jdk18on) version 1.78.1 is confirmed to be the latest release. The dependency addition is appropriate and does not require version changes.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check latest version of BouncyCastle
curl -s "https://search.maven.org/solrsearch/select?q=g:%22org.bouncycastle%22+AND+a:%22bcprov-jdk18on%22&core=gav&rows=1&wt=json" | jq -r '.response.docs[0].v'

Length of output: 169

src/main/resources/lang/en_us/messages.yml (1)

375-376: LGTM: New message added correctly.

The new message IPDB_UNGZIP_FAILED is consistent with the existing style and provides a clear error message for IPDB database decompression failure.

src/main/java/com/ghostchu/peerbanhelper/PeerBanHelperServer.java (3)

10-10: LGTM: BitComet import added correctly.

The new import for BitComet is correctly placed and aligns with the existing import structure. This import is necessary for the BitComet support being added to the application.

---

216-216: LGTM: BitComet support added to createDownloader method.

The new case for "bitcomet" has been correctly added to the switch statement. It follows the existing pattern for other downloaders and properly calls the BitComet.loadFromConfig method with the required parameters. The indentation and formatting are consistent with the existing code.

---

235-235: LGTM: BitComet support added to overloaded createDownloader method.

The new case for "bitcomet" has been correctly added to the switch statement in the overloaded createDownloader method. It is consistent with the changes made in the first createDownloader method and properly calls the BitComet.loadFromConfig method with the required parameters. The indentation and formatting are consistent with the existing code.

src/main/java/com/ghostchu/peerbanhelper/downloader/impl/bitcomet/BitComet.java (1)

282-282: Verify Character Encoding for PeerId

In line 282, PeerId is converted using ISO_8859_1 encoding. Depending on how PeerId is represented, this encoding may not be appropriate.

Ensure that ISO_8859_1 is the correct encoding for decoding PeerId. If PeerId contains binary data or uses a different encoding, consider adjusting accordingly.

To verify the correctness, you can search for the usage of getPeerId() in the codebase:

✅ Verification successful

Character Encoding Verified for PeerId

After reviewing the usage of getPeerId() across the codebase, the use of ISO_8859_1 encoding for converting PeerId is appropriate as it preserves the byte values during the conversion from byte array to String.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the encoding used for PeerId.

# Search for all usages of getPeerId() and check how it's processed.
rg --type java 'getPeerId\(\)' -A 5

Length of output: 14155