A method and system for fine-grained filtering and orchestration of Google Jib mirror layers based on Maven coordinates

Abstract

The application relates to the technical field of container image construction and layered optimization, and provides a Google Jib image layer fine filtering arrangement method based on Maven coordinates, which comprises the following steps: S1: retaining original compatibility of an official layer filtering plug-in configuration and introducing a layer sequence control configuration item; S2: performing full-scan, rule matching and file collection on project dependencies and resource files, cleaning a runtime dependency set, converting coordinates into physical paths, and scanning non-JAR class resource files; S3: performing logical arrangement, merging and structure auditing on the collected image layers, and completing layer sequence sorting according to a layer sequence control matrix; S4: generating a Jib core executable standardized construction instruction based on an ordered layer sequence object, completing container path normalization conversion and metadata maintenance, assembling construction instruction flow according to a preset layer sequence, and delivering the Jib core. The method realizes controllable image layer sequence, supports accurate Maven coordinate filtering, covers all types of file layering, and significantly improves image cache utilization and construction efficiency.

Description

Technical Field

[0001] This invention relates to the technical field of container image building and layer optimization, and in particular to a method and system for fine-grained filtering and orchestration of Google Jib image layers based on Maven coordinates. Background Technology

[0002] With the rapid popularization of cloud-native technologies and the deepening of enterprise-level digital transformation, containerized deployment has become the mainstream form of Java application delivery. Docker images and OCI images, as standard carriers for containerized distribution, directly impact the overall efficiency of application iteration, distribution, deployment, and operation and maintenance management through their build efficiency, layered structure, and cache reuse capabilities. In enterprise-level Java application development scenarios, projects based on the Maven build tool dominate. Traditional Docker image building relies on the Docker daemon, resulting in cumbersome processes, slow build speeds, and heavy dependencies. The Google Jib plugin (jibmavenplugin), with its advantages of eliminating the need for the Docker daemon, lightweight builds, and automated layering, has become the mainstream technology solution for building containerized images for Java applications. It can optimize the image layering structure to a certain extent, improve image push and pull efficiency, and adapt to the large-scale, high-frequency application building and deployment needs of enterprises.

[0003] Currently, the mirror layer filtering extension plugin officially provided by Google Jib still has significant technical shortcomings in actual enterprise-level complex Java project applications, making it difficult to meet the requirements of fine-grained layered control and efficient cache building, as detailed below: (1) Uncontrollable image layer order: The official layer filtering extension plugin only supports creating new image layers and moving files, and cannot adjust or customize the loading order of each layer in the final image. In enterprise-level Java application scenarios with complex dependencies and numerous modules, the loading order of image layers directly determines the cache hit rate during the image building process. Uncontrollable layer order will cause the caching mechanism to fail to play its full role, making it difficult to achieve continuous optimization of image building efficiency.

[0004] (2) Insufficient granularity of filtering rules: The official plugin's filtering rules only support glob wildcard matching based on file paths (such as ** / google-*.jar), and can only filter target files through file path rules. In actual Java development processes, developers generally manage project dependencies based on the Maven coordinate system (groupId:artifactId:version), and are far more familiar with dependency coordinates than with file paths. However, the official plugin does not support defining the dependency ownership layer directly using Maven coordinates, which makes the layered configuration process cumbersome, prone to configuration errors, and raises the threshold for using layered management.

[0005] (3) Inability to filter non-JAR resource files: The official layer filtering plugin is limited to filtering JAR format dependency files and cannot achieve fine-grained layer control over non-JAR resource files included in the application packaging process, including configuration files such as application.yaml, logbackspring.xml, and bootstrap.json, as well as other static resources and script files. These non-JAR resource files also have different change frequencies, and the rationality of their layering directly affects the image layer cache hit rate. Existing technologies cannot manage their layering, further limiting the optimization space for image building and distribution efficiency.

[0006] In summary, existing Google Jib official layer filtering plugins suffer from technical issues such as uncontrollable image layer order, insufficient granularity of filtering rules, and the inability to cover configuration and resource files while only supporting JAR file filtering. These issues prevent the implementation of fine-grained filtering and flexible orchestration of image layers, making it difficult to meet the higher requirements of enterprise-level Java applications for image building efficiency, cache utilization, and ease of layer configuration. Therefore, a more complete and Maven-compatible image layer optimization method is urgently needed to address these shortcomings. Summary of the Invention

[0007] To address the aforementioned issues, the present invention aims to provide a method and system for fine-grained filtering and orchestration of Google Jib image layers based on Maven coordinates. Building upon and enhancing the official Jib layer filtering extension, it enables controllable image layer order, supports precise Maven coordinate filtering, covers layering of all file types, significantly improves image cache utilization and build efficiency, and reduces configuration complexity.

[0008] The above-mentioned objective of this invention is achieved through the following technical solutions: A fine-grained filtering and orchestration method for Google Jib mirror layers based on Maven coordinates includes the following steps: S1: Extend the configuration model and complete the rule parsing initialization, retain the original configuration compatibility of the official layer filtering plugin, introduce layer order control configuration items, extend the Maven coordinate matching rules, parse the project dependency tree and establish a mapping index between coordinates and physical file paths, and finally output a standardized extended configuration model. S2: Performs a full scan of project dependencies and resource files, matches rules and aggregates files, cleans the runtime dependency set, converts coordinates to physical paths, scans non-JAR resource files, and completes the mapping and aggregation of files to the image layer through dual-mode parallel matching. S3: Perform logical arrangement, merging and structural auditing on the collected mirror layers, complete the hierarchical sorting according to the hierarchical order control matrix, perform merging of layers with the same name, removal of empty layers and structural integrity verification, and output standardized ordered layer sequence objects. S4: Generates standardized build instructions executable by the Jib core based on ordered layer sequence objects, completes the normalization transformation of the in-container path and maintains metadata, assembles the build instruction stream according to the preset layer order and delivers it to the Jib kernel, and finally generates and pushes a layer-controlled Docker / OCI image.

[0009] Furthermore, in step S1, the configuration model is expanded and rule parsing initialization is completed, preserving the original configuration compatibility of the official layer filtering plugin, introducing layer order control configuration items, and expanding the Maven coordinate matching rules, specifically: Preservation of compatibility with existing configuration structures: Without modifying the original configuration parsing logic of the official layer filter plugin, the native filters node and glob path matching rules are fully preserved by extending the Configuration class, ensuring that the configuration of historical projects can be loaded transparently, without breaking the compatibility of existing projects, and establishing a stable basic configuration environment for new features; Explicit declaration of hierarchical control configuration items: introduced at the top level of the configuration model. <layerorder>The ordered list configuration item is initialized by the dedicated configuration parsing module when the plugin starts. This module performs deduplication, validity checks, and null value filtering on the layer names in layerOrder, converting them into an ordered layer order control vector, which serves as the core sorting basis for subsequent mirror layer logical orchestration. Multidimensional filtering rule expansion and semantic branch establishment: The parsing logic of the original filters is semantically expanded. In addition to the physical path matching branch, a matching branch based on Maven coordinate mode is added. When the string in the format of groupId:artifactId:version appears in the configuration item, the coordinate matching semantics are automatically triggered, forming a parallel dual-track matching system with the original path wildcard rules.

[0010] Further, in step S1, the project dependency tree is parsed and a mapping index between coordinates and physical file paths is established, ultimately outputting a standardized extended configuration model, specifically: Deep analysis and metadata extraction of project dependency tree: By calling the Maven dependency parsing interface, the POM file of the current project and its complete transitive dependency chain are read in depth, a global dependency tree structure is constructed, and the GAV metadata information of each dependency is extracted to generate a full list of dependency coordinates. Construction of the coordinate-physical file path mapping index: Based on the Maven repository specification and dependency resolution results, each set of Maven coordinates is strongly bound to its physical JAR file path in the local or remote repository, and a coordinate-path mapping index table that supports wildcard fuzzy matching is established to ensure that the coordinate rules at the logical level can be quickly and accurately converted into specific file path sets. Normalization and output of configuration model: The parsed path wildcard rules, coordinate matching rules and hierarchical control vectors are uniformly encapsulated to eliminate data heterogeneity and form a standardized extended configuration model. This model serves as a unified data interface for subsequent file collection, layer allocation and final layer orchestration tasks, ensuring the uniqueness and traceability of data during the execution phase.

[0011] Further, in step S2, a full scan, rule matching, and file aggregation are performed on project dependencies and resource files to clean the runtime dependency set, convert coordinates to physical paths, and scan non-JAR resource files. Specifically: During the initialization phase of the image building task, the project dependencies and resource files are fully scanned and rule-matched through multi-module collaborative parsing, achieving accurate mapping of files to the target image layer and providing core data support for subsequent layer order orchestration. Deep traversal and cleaning of the project runtime dependency system: Start the full dependency resolution process, call the native Maven service to perform a deep traversal of pom.xml and its transitive dependency chain, accurately extract multi-dimensional coordinate metadata including the GAV and classifier of each dependency package during the dependency tree construction process, and remove non-runtime scope dependencies including test and provided according to the build lifecycle to form a pure dependency set containing only the components necessary for container operation. Semantic conversion and dictionary construction from coordinates to physical paths: Based on the Maven standard repository layout specification, the extracted logical coordinates are automatically converted into their absolute physical paths in the local repository or build environment, generating a coordinate-path retrieval dictionary that supports exact matching and wildcard fuzzy matching, realizing a precise mapping from Maven logical coordinate semantics to the underlying file system semantics, and providing a data index for subsequent batch file location. Full scan and feature extraction of non-JAR resource files: Based on the standard directory structure of a Java project, recursively scan the resources directory, configuration file directory, and custom static resource paths to extract all non-JAR type files, including application configuration, log configuration, static web pages, and executable scripts. Redundancy filtering and validity verification are performed during the scanning process to ensure that all resource files involved in image building are fully included in the pending list.

[0012] Furthermore, in step S2, the mapping and aggregation of files to the mirror layer is completed through dual-mode parallel matching, specifically as follows: Priority execution and dual-mode parallel matching of filtering rules: Load the filter sequence in the configuration model and apply the conflict resolution mechanism of subsequent rules first to ensure that the user-defined rules have the highest execution priority. For the dependent JAR set and resource file set, coordinate matching and path wildcard dual-mode verification logic are triggered in parallel. According to the priority order of the rule definition, each file is accurately assigned to the corresponding filtering logic branch. Layer and file set association and deduplication aggregation: The successfully matched physical files are associated with the target layer specified by the rule, and the global deduplication logic of the file dimension is executed during the aggregation process to ensure that any physical file belongs to only one logical image layer. Finally, a structured layer-file set mapping table is produced, which clearly defines the complete set of physical files contained in each custom layer or default layer, and completes the pre-layer preparation for image building.

[0013] Further, in step S3, the collected mirror layers are logically arranged, merged, and structurally audited. The layer order is then sorted according to the layer sequence control matrix. This involves merging layers with the same name, removing empty layers, and verifying structural integrity, ultimately outputting a standardized ordered layer sequence object. Specifically: After all files to be packaged have been mapped and aggregated with the target layer, the image layers are sorted, merged, and verified according to the user configuration to form a final stable and ordered layer structure. Parsing and priority injection of the layer order control matrix: Extract the layerOrder list from the extended configuration model and map it into an ordered logical layer order control matrix. This matrix serves as the highest priority criterion for image layer orchestration and directly determines the physical stacking order of each file layer within the final Docker / OCI image, ensuring that the loading sequence of the image layers is highly consistent with the user-defined business logic. The topology comparison and consistency verification of the mirror layer set traverses the layer-file mapping table generated in step S2, extracts all valid layer names actually generated, performs a topology comparison between the full layer set and the layerOrder control matrix, verifies the completeness of the layer definition, and, based on the constraint logic in the project code, triggers a consistency exception interruption if the actually generated layer is not explicitly declared in the control matrix, thus preventing unexpected offsets of the mirror structure from the source. Linear orchestration and optimization of layer stacking order: Based on the index weights defined in the control matrix, all physical layer objects are linearly sorted. By explicitly controlling the recording order of each layer in the image configuration Manifest, relatively stable layers are placed at the bottom layer and frequently changing layers are placed at the top layer, thereby maximizing the cache hit rate of the image layer. Same-name layer logical merging and storage redundancy elimination: Execute the image layer merging processing logic, and perform atomic merging of physical file sets for layer objects that point to the same toLayer name matched by different filter rules. Automatically perform full deduplication operation to ensure that the same physical file does not have duplicate entries in the logical layer, effectively eliminating storage redundancy and metadata redundancy inside the image. Automated removal of empty layers and structural integrity audit: After sorting and merging are completed, the structural audit process is initiated to automatically identify and remove empty layer objects that do not contain any valid file entries, optimize the number of mirror layers, and perform file ownership uniqueness audit to ensure that each physical file occupies a unique and definite logical position in the ordered layer sequence, eliminating the risk of layer overlap or data overwriting. Standardized encapsulation and distribution of ordered layer sequence objects: The orchestrated, merged, and audited layer structure is encapsulated into standardized ordered layer sequence objects. These objects fully encapsulate the physical indexes, file manifest sets, and corresponding metadata of each layer, serving as the core input data for generating the final Jib build instructions.

[0014] Further, in step S4, standardized build instructions executable by the Jib core are generated based on the ordered layer sequence object, the in-container path normalization transformation and metadata preservation are completed, the build instruction stream is assembled according to the preset layer order and delivered to the Jib kernel, and finally, a layer-controlled Docker / OCI image is generated and pushed, specifically: After completing the logical arrangement of the layer structure and obtaining the ordered and merged final layer sequence object, standardized build instructions that can be executed by the Jib core are generated based on this structure to ensure that the image layer order, file content and user configuration are completely consistent. Deep validation of orchestration layer objects and instruction set preprocessing: Read and parse the ordered layer sequence objects generated in step S3, perform final validation on the legality of physical paths, the integrity of file entries and the order of hierarchical topology contained in each layer, perform logical closed-loop audit before instruction generation to ensure that no duplicate entries or illegal empty layers enter the build engine, and establish a security boundary for the reliability of subsequent instruction generation. Atomic mapping of image build plan: Based on the ContainerBuildPlan protocol of Jib extended API, the sorted logical layers are mapped to the corresponding FileEntriesLayer atomic build objects in sequence. For each layer in the sequence, the Builder pattern is used to build a structured description instruction containing a unique layer identifier, load weight and a set of file entries. Normalization of paths within the container and preservation of metadata: Perform normalization of physical file paths to container mount paths, unify local repository paths and project build paths to target paths within the image, and fully inherit and apply metadata including file permissions and modification timestamps during this process to ensure that the image content conforms to OCI standard specifications at both the logical and physical levels. Linear assembly of the build instruction flow and injection of environment state: Using the ContainerBuildPlan construction pattern, all layer instructions are assembled into the build plan in a preset linear order. The basic metadata configuration of the image is injected synchronously in the instruction flow to form a standardized set of build instructions containing complete layer order logic and runtime environment parameters. Instruction delivery and kernel decoupling based on the SPI protocol: The assembled build plan object is safely returned to the Jib core execution engine through the Jib plugin extension interface SPI. This delivery process adopts a declarative configuration model, which does not require intervention in the underlying storage and physical write mechanism of the kernel. It only controls the physical location and file ownership of the control layer through standard instructions, thereby achieving efficient decoupling between custom layered logic and the official build kernel. Deterministic generation and distribution of layer-controlled images: After receiving the instruction stream, the Jib core engine performs physical packaging and hash calculations strictly according to the ordered layer sequence defined in ContainerBuildPlan. Finally, it generates a target Docker / OCI image with highly controllable layer order, accurate content, and optimal cache utilization. Based on the configuration, it completes the local persistent storage or remote image repository distribution and push tasks of the image.

[0015] A fine-grained filtering orchestration system for Google Jib mirror layers based on Maven coordinates, for performing the fine-grained filtering orchestration method for Google Jib mirror layers based on Maven coordinates as described above, includes: The configuration parsing module is used to extend the configuration model and complete the rule parsing initialization. It retains the original configuration compatibility of the official layer filtering plugin, introduces layer order control configuration items, extends Maven coordinate matching rules, parses the project dependency tree and establishes a mapping index between coordinates and physical file paths, and finally outputs a standardized extended configuration model. The file collection module is used to perform a full scan of project dependencies and resource files, rule matching, and file collection. It cleans the runtime dependency set, converts coordinates into physical paths, scans non-JAR resource files, and completes the mapping and collection of files to the image layer through dual-mode parallel matching. The layer orchestration audit module is used to logically orchestrate, merge, and audit the structure of the collected mirror layers. It completes the layer sorting according to the layer order control matrix, performs the merging of layers with the same name, the removal of empty layers, and the structural integrity verification, and outputs a standardized ordered layer sequence object. The image building module is used to generate standardized build instructions that can be executed by the Jib core based on ordered layer sequence objects, complete the normalization transformation of the in-container path and maintain the metadata, assemble the build instruction stream according to the preset layer order and deliver it to the Jib kernel, and finally generate and push a layer-controlled Docker / OCI image.

[0016] A computer device includes a memory and one or more processors, the memory storing computer code that, when executed by the one or more processors, causes the one or more processors to perform the method described above.

[0017] A computer-readable storage medium storing computer code that, when executed, performs the method described above.

[0018] Compared with the prior art, the present invention has at least one of the following beneficial effects: (1) This invention introduces <layerorder>The layer order control mechanism allows for customizable and controllable orchestration of image layer loading order, placing stable dependency layers at the bottom and volatile layers at the top, maximizing the use of Docker layer caching mechanism, significantly improving image building, pushing and pulling speed, especially in complex dependency projects where it can greatly reduce the time spent on repeated builds.

[0019] (2) This invention supports dependency matching and layering directly based on Maven coordinates (groupId:artifactId:version), abandoning the cumbersome configuration method that only supports file path wildcards, which is more in line with the daily usage habits of Java developers, greatly reducing the threshold of layered configuration, reducing configuration errors, and improving the convenience and accuracy of layered management.

[0020] (3) This invention breaks through the limitation that the official plugin can only filter JAR dependency packages, and realizes unified layering and refined management of all types of build files such as configuration files, static resources, and script files. It fully covers all files in the image, so that resources with different change frequencies can be layered independently, further improving cache utilization and image structure rationality.

[0021] (4) While expanding its functions, this invention is fully compatible with the original configuration of the official Jib layer filtering plugin. It can be transparently integrated without modifying the configuration of historical projects, without damaging the existing project structure, and has good backward compatibility. It can be quickly implemented and smoothly upgraded in enterprise-level Java projects.

[0022] (5) This invention eliminates redundancy and structural risks within the image through layer merging, deduplication, empty layer removal and structural auditing mechanisms, ensuring unique file ownership and stable and standardized layer structure, making the final image volume more concise, the structure more controllable and the operation more stable.

[0023] (6) This invention is based on the standard SPI interface and is decoupled from the Jib kernel. It does not intrude on the underlying build logic, has high stability and scalability, and can be adapted to different versions of Jib plugins and various Maven projects, meeting the needs of enterprises for large-scale and standardized container image building. Attached Figure Description

[0024] Figure 1 This is an overall flowchart of the fine-grained filtering and orchestration method for Google Jib mirror layers based on Maven coordinates according to the present invention; Figure 2 This is a diagram illustrating the overall structure of the Google Jib mirror layer fine-grained filtering and orchestration method based on Maven coordinates, as described in this invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms "a," "an," "the," and "the" used herein may also include the plural forms. It should be further understood that the term "comprising" as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0027] To address the problems existing in the prior art, this invention improves and enhances upon the Google Jib official layer filtering extension, proposing a refined filtering and orchestration method and system for the Google Jib mirror layer based on Maven coordinates. Its core improvements are as follows: (1) Support for sequential arrangement of mirror layers: This invention introduces in the plugin configuration <layerorder>The configuration option allows users to customize the loading order of all image layers (including default and newly added layers) in the final image. By controlling the stacking order of image layers, the system can maximize the use of Docker's image layer caching mechanism and significantly improve the speed of subsequent image building.

[0028] (2) Filtering rules based on Maven coordinates: This invention extends the filtering rules to support matching dependencies using Maven coordinates (groupId:artifactId:version) pattern. Users can easily group internal dependencies (such as com.hd123.::) into an independent image layer, or group all snapshot version dependencies (:*:*SNAPSHOT) into the same image layer. The configuration method is more in line with the cognitive habits of developers and effectively reduces the threshold for use.

[0029] (3) Support for filtering all build files: This invention breaks through the limitation that the official plugin can only filter JAR files and extends the filtering scope to all build files in the image. Users can use glob wildcards or Maven coordinates to perform filtering and layering operations on various files that require fine control, such as configuration files, static resources, and script files.

[0030] The following is an illustration through specific examples: First Embodiment like Figure 1 As shown, this embodiment provides a fine-grained filtering and orchestration method for Google Jib mirror layers based on Maven coordinates, including the following steps: S1: Extend the configuration model and complete the rule parsing initialization, retain the original configuration compatibility of the official layer filtering plugin, introduce layer order control configuration items, extend Maven coordinate matching rules, parse the project dependency tree and establish a mapping index between coordinates and physical file paths, and finally output a standardized extended configuration model.

[0031] In this embodiment, step S1 specifically includes: (1) Preservation of compatibility with existing configuration structure: Without modifying the original configuration parsing logic of the official layer filter plugin, the original filter node and glob path matching rules are fully preserved by extending the Configuration class, ensuring that the configuration of historical projects can be loaded transparently, without breaking the compatibility of existing projects, and establishing a stable basic configuration environment for new features; (2) Explicit declaration of hierarchical control configuration items: introduced at the top level of the configuration model <layerorder>The ordered list configuration item is initialized by the dedicated configuration parsing module when the plugin starts. This module performs deduplication, validity checks, and null value filtering on the layer names in layerOrder, converting them into an ordered layer order control vector, which serves as the core sorting basis for subsequent mirror layer logical orchestration. (3) Extension of multidimensional filtering rules and establishment of semantic branches: The parsing logic of the original filters is semantically extended. In addition to the physical path matching branch, a matching branch based on Maven coordinate mode is added. When the string in the format of groupId:artifactId:version appears in the configuration item, the coordinate matching semantics are automatically triggered, forming a parallel dual-track matching system with the original path wildcard rules.

[0032] (4) Deep parsing and metadata extraction of project dependency tree: By calling the Maven dependency parsing interface, the POM file of the current project and its complete transitive dependency chain are read in depth, a global dependency tree structure is constructed, and the GAV metadata information of each dependency is extracted and a full dependency coordinate list is generated. (5) Construction of coordinate and physical file path mapping index: Based on the Maven repository specification and dependency resolution results, each set of Maven coordinates is strongly bound to its physical JAR file path in the local or remote repository, and a coordinate-path mapping index table that supports wildcard fuzzy matching is established to ensure that the coordinate rules at the logical level can be quickly and accurately converted into a specific set of file paths. (6) Normalization encapsulation and output of configuration model: The parsed path wildcard rules, coordinate matching rules and hierarchical control vectors are uniformly encapsulated to eliminate data heterogeneity and form a standardized extended configuration model. This model serves as a unified data interface for subsequent file collection, layer allocation and final layer orchestration tasks, ensuring the uniqueness and traceability of data during the execution phase.

[0033] Step S1 above, through a six-in-one design encompassing compatibility with existing configurations, extended hierarchical control, added coordinate matching, dependency tree parsing, coordinate path mapping, and configuration model encapsulation, completes the core rule initialization and data preparation of this invention. This step, without altering the underlying logic of the official Jib plugin, precisely integrates the Maven coordinate system familiar to developers with the image layering rules. This ensures seamless migration of historical projects without compatibility risks, and through key structures such as hierarchical vectors, dual-track matching mechanisms, and coordinate path indexes, provides unified, standardized, and traceable data support for subsequent file collection, layered orchestration, and image building. It achieves configurability, parsing, and controllability of layering rules from the source, laying a stable and reliable foundation for the entire image layer fine-grained filtering and orchestration process.

[0034] S2: Performs a full scan, rule matching, and file aggregation on project dependencies and resource files, cleans the runtime dependency set, converts coordinates into physical paths, scans non-JAR resource files, and completes the mapping and aggregation of files to the image layer through dual-mode parallel matching.

[0035] In this embodiment, step S2 specifically includes: During the initialization phase of the image building task, the project dependencies and resource files are fully scanned and rule-matched through multi-module collaborative parsing, achieving accurate mapping of files to the target image layer and providing core data support for subsequent layer order orchestration. (1) Deep traversal and cleaning of the dependency system during project runtime: Start the full dependency resolution process, call the native Maven service to perform a deep traversal of pom.xml and its transitive dependency chain, accurately extract multi-dimensional coordinate metadata including the GAV and classifier of each dependency package during the dependency tree construction process, and remove non-runtime scope dependencies including test and provided according to the build life cycle to form a pure dependency set containing only the components necessary for container operation. (2) Semantic conversion and dictionary construction from coordinates to physical paths: Based on the Maven standard repository layout specification, the extracted logical coordinates are automatically converted into their absolute physical paths in the local repository or build environment, generating a coordinate-path retrieval dictionary that supports exact matching and wildcard fuzzy matching, realizing accurate mapping from Maven logical coordinate semantics to underlying file system semantics, and providing data index for subsequent batch file location. (3) Full scan and feature extraction of non-JAR resource files: Based on the standard directory structure of Java projects, recursively scan the resources directory, configuration file directory and custom static resource paths, and extract all non-JAR type files, including application configuration, log configuration, static web pages and execution scripts. Redundancy filtering and validity verification are performed during the scanning process to ensure that all resource files involved in image building are fully included in the pending list.

[0036] (4) Priority execution of filtering rules and parallel matching of dual modes: Load the filter sequence in the configuration model and apply the conflict resolution mechanism of subsequent rules first to ensure that the rules defined by the user later have the highest execution priority. For the dependent JAR set and resource file set, trigger the coordinate matching and path wildcard dual mode verification logic in parallel. According to the priority order of the rule definition, each file is accurately assigned to the corresponding filtering logic branch. (5) Association and deduplication of layers and file sets: The matched physical files are associated with the target layer toLayer specified by the rule. During the aggregation process, global deduplication logic of the file dimension is executed to ensure that any physical file belongs to only one logical image layer. Finally, a structured layer-file set mapping table is produced, which clearly defines the complete set of physical files contained in each custom layer or default layer, and completes the pre-layer preparation for image construction.

[0037] Step S2, as the core data processing step of the image layering invention, aims at "full scanning, precise matching, and orderly aggregation," deeply integrating the configuration rules formed in the previous steps with the actual dependencies and resource files of the current project. This step first filters invalid dependency packages through runtime dependency cleaning to ensure the image content is concise and reliable; then, through automatic conversion from coordinates to physical paths, it transforms the logical configurations intended for developers into file addresses recognizable by the build engine; simultaneously, it comprehensively covers JAR packages and non-JAR files such as configurations, static resources, and scripts, breaking through the limitation of traditional tools that can only handle dependency packages. Through a dual-mode parallel matching mechanism of "subsequent rule priority," it balances configuration flexibility and execution efficiency. Then, through file deduplication and layer binding, it ensures that each file uniquely belongs to the target layer, ultimately forming a structured layer file mapping relationship. This ensures that the layering results are accurate and conflict-free, and provides a complete and reliable data foundation for subsequent layer order arrangement and structure auditing, making the entire refined layering process implementable, reproducible, and verifiable.

[0038] S3: Perform logical orchestration, merging, and structural auditing on the collected mirror layers. Complete the hierarchical sorting based on the hierarchical order control matrix, perform merging of layers with the same name, removal of empty layers, and structural integrity verification, and output standardized ordered layer sequence objects.

[0039] In this embodiment, step S3 specifically includes: After all files to be packaged have been mapped and aggregated with the target layer, the image layers are sorted, merged, and verified according to the user configuration to form a final stable and ordered layer structure. (1) Parsing and priority injection of the layer order control matrix: Extract the layerOrder list from the extended configuration model and map it into an ordered logical layer order control matrix. This matrix serves as the highest priority criterion for image layer orchestration and directly determines the physical stacking order of each file layer in the final Docker / OCI image, ensuring that the loading sequence of the image layer is highly consistent with the user-defined business logic. (2) Topology comparison and consistency verification of the mirror layer set: Traverse the layer-file mapping table generated in step S2, extract all valid layer names actually generated, compare the full layer set with the layerOrder control matrix to verify the completeness of the layer definition, and according to the constraint logic in the project code, if the actually generated layer is not explicitly declared in the control matrix, a consistency exception interruption is triggered to prevent unexpected offset of the mirror structure from the source. (3) Linear arrangement and optimization of the stacking order of the layers: Based on the index weights defined in the control matrix, all physical layer objects are linearly sorted. By explicitly controlling the recording order of each layer in the image configuration Manifest, relatively stable layers are placed at the bottom layer and frequently changing layers are placed at the top layer, thereby maximizing the cache hit rate of the image layer. (4) Merging of layer with the same name and eliminating storage redundancy: The merge processing logic of the image layer is executed. For layer objects that are matched by different filter rules and point to the same toLayer name, the physical file set is atomically merged and the full deduplication operation is automatically performed to ensure that the same physical file does not have duplicate entries in the logical layer, effectively eliminating storage redundancy and metadata redundancy inside the image. (5) Automatic removal of empty layers and structural integrity audit: After sorting and merging are completed, the structural audit process is started to automatically identify and remove empty layer objects that do not contain any valid file entries, optimize the number of mirror layers, and perform file ownership uniqueness audit to ensure that each physical file occupies a unique and definite logical position in the ordered layer sequence, and eliminate the risk of layer overlap or data overwriting. (6) Standardized encapsulation and distribution of ordered layer sequence objects: The layer structure after orchestration, merging and auditing is encapsulated into standardized ordered layer sequence objects. These objects fully encapsulate the physical indexes, file list sets and their corresponding metadata of each layer, serving as the core input data for generating the final Jib build instructions.

[0040] Step S3 is a crucial step in achieving refined orchestration and structural optimization of the image layer in this invention. Building upon the layer-file mapping relationship established in Step S2, it optimizes the entire process of the image layer from basic aggregation to standardized output, with "orderliness, compliance, and no redundancy" as the core objective. This step first transforms user-defined layer order requirements into executable orchestration guidelines through the parsing and injection of the layer order control matrix, ensuring that the image layer stacking order perfectly aligns with business logic. Then, through topology comparison and consistency verification, it avoids image structure anomalies caused by missing layer definitions from the source, ensuring the standardization of the orchestration process. Through linear sorting optimization, stable and volatile layers are rationally layered, maximizing the value of image caching and reducing construction and distribution time. Through merging layers with the same name, removing empty layers, and integrity auditing, it effectively eliminates storage redundancy and data conflict risks, ensuring a streamlined and logically clear image layer structure. Finally, the optimized layer structure is encapsulated into a standardized ordered layer sequence object, realizing the unified and standardized output of layer information. This not only provides standardized input for the subsequent generation of build instructions, but also further consolidates the foundation for controllable and traceable image layers, ensuring that the final output image structure is stable and has optimal performance.

[0041] S4: Generates standardized build instructions executable by the Jib core based on ordered layer sequence objects, completes the normalization transformation of the in-container path and maintains metadata, assembles the build instruction stream according to the preset layer order and delivers it to the Jib kernel, and finally generates and pushes a layer-controlled Docker / OCI image.

[0042] In this embodiment, step S4 specifically includes: After completing the logical arrangement of the layer structure and obtaining the ordered and merged final layer sequence object, standardized build instructions that can be executed by the Jib core are generated based on this structure to ensure that the image layer order, file content and user configuration are completely consistent. (1) Deep verification of orchestration layer objects and instruction set preprocessing: Read and parse the ordered layer sequence objects generated in step S3, perform final verification on the legality of physical paths, the integrity of file entries and the order of hierarchical topology in each layer, perform logical closed-loop audit before instruction generation, ensure that no duplicate entries or illegal empty layers enter the build engine, and establish a security boundary for the reliability of subsequent instruction generation. (2) Atomic mapping of image build plan: Based on the ContainerBuildPlan protocol of Jib extended API, the sorted logical layers are mapped to the corresponding FileEntriesLayer atomic build objects in sequence. For each layer in the sequence, the Builder pattern is used to build a structured description instruction containing a unique layer identifier, loading weight and a set of file entries. (3) Normalization of paths within the container and preservation of metadata: Perform normalization of physical file paths to container mount paths, convert local repository paths and project build paths into target paths within the image, and fully inherit and apply metadata including file permissions and modification timestamps during this process to ensure that the image content conforms to OCI standard specifications at both the logical and physical levels. (4) Linear assembly of the instruction flow and injection of environment state: Using the construction mode of ContainerBuildPlan, all layer instructions are assembled into the build plan in a preset linear order, and the basic metadata configuration of the image is injected synchronously in the instruction flow to form a standardized set of build instructions containing complete layer order logic and runtime environment parameters. (5) Instruction delivery and kernel decoupling execution based on SPI protocol: The assembled build plan object is safely returned to the Jib core execution engine through the Jib plugin extension interface SPI. This delivery process adopts a declarative configuration model, without interfering with the underlying storage and physical write mechanism of the kernel. It only controls the physical location and file ownership of the control layer through standard instructions, thereby achieving efficient decoupling between custom layered logic and the official build kernel. (6) Deterministic generation and distribution of layer-controlled images: After receiving the instruction stream, the Jib core engine performs physical packaging and hash calculation in strict accordance with the ordered layer sequence defined in ContainerBuildPlan. Finally, it generates a target Docker / OCI image with highly controllable layer order, accurate content and optimal cache utilization. It also completes the local persistent storage or remote image repository distribution and push tasks of the image according to the configuration.

[0043] Step S4, as the final execution stage of image building in this invention, is the core hub connecting the previous layered configuration and the final deployable image. Its core objective is to transform the ordered layer structure generated in the previous steps into standardized build instructions that can be recognized and executed by the Jib core, and finally generate a Docker / OCI image that meets the expected layer order, is free of redundancy, and can be directly deployed, ensuring the closed-loop implementation of the entire process.

[0044] This step uses the standardized ordered layer sequence object output from step S3 as its core input, breaking through the limitations of traditional image building where "layer order is uncontrollable and configuration and execution are disconnected." Through multi-module collaborative execution, it achieves precise transformation from logical configuration to the actual image. First, through deep verification and preprocessing of the ordered layer sequence object, it checks the legality of paths, the integrity of files, and the rationality of layer order, building a secure and reliable foundation for instruction generation and preventing invalid entries or illegal configurations from entering the build process. Second, relying on the Jib extended API and the ContainerBuildPlan protocol, it transforms the logical layer ordering and file mapping relationships into atomic build instructions recognizable by the Jib kernel, ensuring that the loading order and file ownership of each layer are completely consistent with the user's preset. Third, through path normalization transformation and metadata preservation, it achieves precise mapping between local file paths and container internal paths, taking into account both OCI standard specifications and the original file attributes. This ensures the standardization and consistency of the image content. Simultaneously, the SPI protocol decouples the execution of build commands from the Jib core, avoiding interference with the kernel's underlying storage and write logic while precisely controlling the image layer order and file distribution, thus preventing conflicts between custom logic and the official build mechanism. Finally, standardized packaging and hash verification generate a target image with controllable layer order and efficient caching, and push it to local storage or a remote repository, truly achieving "what you get after configuration." This solves the pain points of chaotic layer order, low cache utilization, and disconnect between configuration and execution in traditional image building, while ensuring the stability and traceability of image deployment, perfectly adapting to enterprise-level large-scale deployment and iteration needs.

[0045] Second Embodiment like Figure 2 As shown, this embodiment provides a Google Jib mirror layer fine-grained filtering orchestration system based on Maven coordinates for executing the Google Jib mirror layer fine-grained filtering orchestration method based on Maven coordinates as described in the first embodiment, comprising: The configuration parsing module is used to extend the configuration model and complete the rule parsing initialization. It retains the original configuration compatibility of the official layer filtering plugin, introduces layer order control configuration items, extends Maven coordinate matching rules, parses the project dependency tree and establishes a mapping index between coordinates and physical file paths, and finally outputs a standardized extended configuration model. The file aggregation module is used to perform a full scan of project dependencies and resource files, rule matching, and file aggregation. It cleans the runtime dependency set, converts coordinates into physical paths, scans non-JAR resource files, and completes the mapping and aggregation of files to the image layer through dual-mode parallel matching. The layer orchestration audit module is used to logically orchestrate, merge, and audit the structure of the collected mirror layers. It completes the layer sorting according to the layer order control matrix, performs the merging of layers with the same name, the removal of empty layers, and the structural integrity verification, and outputs a standardized ordered layer sequence object. The image building module is used to generate standardized build instructions that can be executed by the Jib core based on ordered layer sequence objects, complete the normalization transformation of the in-container path and maintain the metadata, assemble the build instruction stream according to the preset layer order and deliver it to the Jib kernel, and finally generate and push a layer-controlled Docker / OCI image.

[0046] A computer-readable storage medium stores computer code that, when executed, performs the methods described above. Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0047] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

[0048] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0049] It should be noted that the above embodiments can be freely combined as needed. The above description is only a preferred embodiment of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.< / layerorder> < / layerorder> < / layerorder> < / layerorder>

Claims

1. A method for fine-grained filtering and orchestration of Google Jib mirror layers based on Maven coordinates, characterized in that, Includes the following steps: S1: Extend the configuration model and complete the rule parsing initialization, retain the original configuration compatibility of the official layer filtering plugin, introduce layer order control configuration items, extend the Maven coordinate matching rules, parse the project dependency tree and establish a mapping index between coordinates and physical file paths, and finally output a standardized extended configuration model. S2: Performs a full scan of project dependencies and resource files, matches rules and aggregates files, cleans the runtime dependency set, converts coordinates to physical paths, scans non-JAR resource files, and completes the mapping and aggregation of files to the image layer through dual-mode parallel matching. S3: Perform logical arrangement, merging and structural auditing on the collected mirror layers, complete the hierarchical sorting according to the hierarchical order control matrix, perform merging of layers with the same name, removal of empty layers and structural integrity verification, and output standardized ordered layer sequence objects. S4: Generates standardized build instructions executable by the Jib core based on ordered layer sequence objects, completes the normalization transformation of the in-container path and maintains metadata, assembles the build instruction stream according to the preset layer order and delivers it to the Jib kernel, and finally generates and pushes a layer-controlled Docker / OCI image.

2. The method for fine-grained filtering and orchestration of Google Jib mirror layers based on Maven coordinates according to claim 1, characterized in that, In step S1, the configuration model is extended and rule parsing initialization is completed. The original configuration compatibility of the official layer filtering plugin is preserved, a layer order control configuration item is introduced, and the Maven coordinate matching rules are extended, specifically as follows: Preservation of compatibility with existing configuration structures: Without modifying the original configuration parsing logic of the official layer filter plugin, the native filters node and glob path matching rules are fully preserved by extending the Configuration class, ensuring that the configuration of historical projects can be loaded transparently, without breaking the compatibility of existing projects, and establishing a stable basic configuration environment for new features; Explicit declaration of hierarchical control configuration items: introduced at the top level of the configuration model. <layerorder> The ordered list configuration item is initialized by the dedicated configuration parsing module when the plugin starts. This module performs deduplication, validity checks, and null value filtering on the layer names in layerOrder, converting them into an ordered layer order control vector, which serves as the core sorting basis for subsequent mirror layer logical orchestration.< / layerorder> Multidimensional filtering rule expansion and semantic branch establishment: The parsing logic of the original filters is semantically expanded. In addition to the physical path matching branch, a matching branch based on Maven coordinate mode is added. When the string in the format of groupId:artifactId:version appears in the configuration item, the coordinate matching semantics are automatically triggered, forming a parallel dual-track matching system with the original path wildcard rules.

3. The method for fine-grained filtering and orchestration of Google Jib mirror layers based on Maven coordinates according to claim 1, characterized in that, In step S1, the project dependency tree is parsed and a mapping index between coordinates and physical file paths is established. Finally, a standardized extended configuration model is output, specifically: Deep analysis and metadata extraction of project dependency tree: By calling the Maven dependency parsing interface, the POM file of the current project and its complete transitive dependency chain are read in depth, a global dependency tree structure is constructed, and the GAV metadata information of each dependency is extracted to generate a full list of dependency coordinates. Construction of the coordinate-physical file path mapping index: Based on the Maven repository specification and dependency resolution results, each set of Maven coordinates is strongly bound to its physical JAR file path in the local or remote repository, and a coordinate-path mapping index table that supports wildcard fuzzy matching is established to ensure that the coordinate rules at the logical level can be quickly and accurately converted into specific file path sets. Normalization and output of configuration model: The parsed path wildcard rules, coordinate matching rules and hierarchical control vectors are uniformly encapsulated to eliminate data heterogeneity and form a standardized extended configuration model. This model serves as a unified data interface for subsequent file collection, layer allocation and final layer orchestration tasks, ensuring the uniqueness and traceability of data during the execution phase.

4. The method for fine-grained filtering and orchestration of Google Jib mirror layers based on Maven coordinates according to claim 1, characterized in that, In step S2, a full scan, rule matching, and file aggregation are performed on project dependencies and resource files to clean the runtime dependency set, convert coordinates to physical paths, and scan non-JAR resource files. Specifically: During the initialization phase of the image building task, the project dependencies and resource files are fully scanned and rule-matched through multi-module collaborative parsing, achieving accurate mapping of files to the target image layer and providing core data support for subsequent layer order orchestration. Deep traversal and cleaning of the project runtime dependency system: Start the full dependency resolution process, call the native Maven service to perform a deep traversal of pom.xml and its transitive dependency chain, accurately extract multi-dimensional coordinate metadata including the GAV and classifier of each dependency package during the dependency tree construction process, and remove non-runtime scope dependencies including test and provided according to the build lifecycle to form a pure dependency set containing only the components necessary for container operation. Semantic conversion and dictionary construction from coordinates to physical paths: Based on the Maven standard repository layout specification, the extracted logical coordinates are automatically converted into their absolute physical paths in the local repository or build environment, generating a coordinate-path retrieval dictionary that supports exact matching and wildcard fuzzy matching, realizing a precise mapping from Maven logical coordinate semantics to the underlying file system semantics, and providing a data index for subsequent batch file location. Full scan and feature extraction of non-JAR resource files: Based on the standard directory structure of a Java project, recursively scan the resources directory, configuration file directory, and custom static resource paths to extract all non-JAR type files, including application configuration, log configuration, static web pages, and executable scripts. Redundancy filtering and validity verification are performed during the scanning process to ensure that all resource files involved in image building are fully included in the pending list.

5. The method for fine-grained filtering and orchestration of Google Jib mirror layers based on Maven coordinates according to claim 1, characterized in that, In step S2, the mapping and aggregation of files to the mirror layer is completed through dual-mode parallel matching, specifically as follows: Priority execution and dual-mode parallel matching of filtering rules: Load the filter sequence in the configuration model and apply the conflict resolution mechanism of subsequent rules first to ensure that the user-defined rules have the highest execution priority. For the dependent JAR set and resource file set, coordinate matching and path wildcard dual-mode verification logic are triggered in parallel. According to the priority order of the rule definition, each file is accurately assigned to the corresponding filtering logic branch. Layer and file set association and deduplication aggregation: The successfully matched physical files are associated with the target layer specified by the rule, and the global deduplication logic of the file dimension is executed during the aggregation process to ensure that any physical file belongs to only one logical image layer. Finally, a structured layer-file set mapping table is produced, which clearly defines the complete set of physical files contained in each custom layer or default layer, and completes the pre-layer preparation for image building.

6. The method for fine-grained filtering and orchestration of Google Jib mirror layers based on Maven coordinates according to claim 1, characterized in that, In step S3, the collected mirror layers are logically arranged, merged, and structurally audited. The layer order is then sorted according to the layer sequence control matrix. This involves merging layers with the same name, removing empty layers, and verifying structural integrity. The result is a standardized ordered layer sequence object, specifically: After all files to be packaged have been mapped and aggregated with the target layer, the image layers are sorted, merged, and verified according to the user configuration to form a final stable and ordered layer structure. Parsing and priority injection of the layer order control matrix: Extract the layerOrder list from the extended configuration model and map it into an ordered logical layer order control matrix. This matrix serves as the highest priority criterion for image layer orchestration and directly determines the physical stacking order of each file layer within the final Docker / OCI image, ensuring that the loading sequence of the image layers is highly consistent with the user-defined business logic. The topology comparison and consistency verification of the mirror layer set traverses the layer-file mapping table generated in step S2, extracts all valid layer names actually generated, performs a topology comparison between the full layer set and the layerOrder control matrix, verifies the completeness of the layer definition, and, based on the constraint logic in the project code, triggers a consistency exception interruption if the actually generated layer is not explicitly declared in the control matrix, thus preventing unexpected offsets of the mirror structure from the source. Linear orchestration and optimization of layer stacking order: Based on the index weights defined in the control matrix, all physical layer objects are linearly sorted. By explicitly controlling the recording order of each layer in the image configuration Manifest, relatively stable layers are placed at the bottom layer and frequently changing layers are placed at the top layer, thereby maximizing the cache hit rate of the image layer. Same-name layer logical merging and storage redundancy elimination: Execute the image layer merging processing logic, and perform atomic merging of physical file sets for layer objects that point to the same toLayer name matched by different filter rules. Automatically perform full deduplication operation to ensure that the same physical file does not have duplicate entries in the logical layer, effectively eliminating storage redundancy and metadata redundancy inside the image. Automated removal of empty layers and structural integrity audit: After sorting and merging are completed, the structural audit process is initiated to automatically identify and remove empty layer objects that do not contain any valid file entries, optimize the number of mirror layers, and perform file ownership uniqueness audit to ensure that each physical file occupies a unique and definite logical position in the ordered layer sequence, eliminating the risk of layer overlap or data overwriting. Standardized encapsulation and distribution of ordered layer sequence objects: The orchestrated, merged, and audited layer structure is encapsulated into standardized ordered layer sequence objects. These objects fully encapsulate the physical indexes, file manifest sets, and corresponding metadata of each layer, serving as the core input data for generating the final Jib build instructions.

7. The method for fine-grained filtering and orchestration of Google Jib mirror layers based on Maven coordinates according to claim 1, characterized in that, In step S4, standardized build instructions executable by the Jib core are generated based on the ordered layer sequence object. Path normalization and metadata preservation within the container are completed. The build instruction stream is assembled according to the preset layer order and delivered to the Jib kernel. Finally, a layer-controlled Docker / OCI image is generated and pushed. Specifically: After completing the logical arrangement of the layer structure and obtaining the ordered and merged final layer sequence object, standardized build instructions that can be executed by the Jib core are generated based on this structure to ensure that the image layer order, file content and user configuration are completely consistent. Deep validation of orchestration layer objects and instruction set preprocessing: Read and parse the ordered layer sequence objects generated in step S3, perform final validation on the legality of physical paths, the integrity of file entries and the order of hierarchical topology contained in each layer, perform logical closed-loop audit before instruction generation to ensure that no duplicate entries or illegal empty layers enter the build engine, and establish a security boundary for the reliability of subsequent instruction generation. Atomic mapping of image build plan: Based on the ContainerBuildPlan protocol of Jib extended API, the sorted logical layers are mapped to the corresponding FileEntriesLayer atomic build objects in sequence. For each layer in the sequence, the Builder pattern is used to build a structured description instruction containing a unique layer identifier, load weight and a set of file entries. Normalization of paths within the container and preservation of metadata: Perform normalization of physical file paths to container mount paths, unify local repository paths and project build paths to target paths within the image, and fully inherit and apply metadata including file permissions and modification timestamps during this process to ensure that the image content conforms to OCI standard specifications at both the logical and physical levels. Linear assembly of the build instruction flow and injection of environment state: Using the ContainerBuildPlan construction pattern, all layer instructions are assembled into the build plan in a preset linear order. The basic metadata configuration of the image is injected synchronously in the instruction flow to form a standardized set of build instructions containing complete layer order logic and runtime environment parameters. Instruction delivery and kernel decoupling based on the SPI protocol: The assembled build plan object is safely returned to the Jib core execution engine through the Jib plugin extension interface SPI. This delivery process adopts a declarative configuration model, which does not require intervention in the underlying storage and physical write mechanism of the kernel. It only controls the physical location and file ownership of the control layer through standard instructions, thereby achieving efficient decoupling between custom layered logic and the official build kernel. Deterministic generation and distribution of layer-controlled images: After receiving the instruction stream, the Jib core engine performs physical packaging and hash calculations strictly according to the ordered layer sequence defined in ContainerBuildPlan. Finally, it generates a target Docker / OCI image with highly controllable layer order, accurate content, and optimal cache utilization. Based on the configuration, it completes the local persistent storage or remote image repository distribution and push tasks of the image.

8. A Google Jib mirror layer fine-grained filtering orchestration system based on Maven coordinates for executing the fine-grained filtering orchestration method based on Maven coordinates as described in any one of claims 1-7, characterized in that, include: The configuration parsing module is used to extend the configuration model and complete the rule parsing initialization. It retains the original configuration compatibility of the official layer filtering plugin, introduces layer order control configuration items, extends Maven coordinate matching rules, parses the project dependency tree and establishes a mapping index between coordinates and physical file paths, and finally outputs a standardized extended configuration model. The file collection module is used to perform a full scan of project dependencies and resource files, rule matching, and file collection. It cleans the runtime dependency set, converts coordinates into physical paths, scans non-JAR resource files, and completes the mapping and collection of files to the image layer through dual-mode parallel matching. The layer orchestration audit module is used to logically orchestrate, merge, and audit the structure of the collected mirror layers. It completes the layer sorting according to the layer order control matrix, performs the merging of layers with the same name, the removal of empty layers, and the structural integrity verification, and outputs a standardized ordered layer sequence object. The image building module is used to generate standardized build instructions that can be executed by the Jib core based on ordered layer sequence objects, complete the normalization transformation of the in-container path and maintain the metadata, assemble the build instruction stream according to the preset layer order and deliver it to the Jib kernel, and finally generate and push a layer-controlled Docker / OCI image.

9. A computer device, characterized in that, The device includes a memory and one or more processors, wherein the memory stores computer code that, when executed by the one or more processors, causes the one or more processors to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer code, and when the computer code is executed, the method as described in any one of claims 1 to 7 is performed.

Images