Dockerized workspace

[zhichli]

Detailed Description of Changes in the PR: Dockerized Workspace

Changes Made to the Code:

1. Addition of .dockerignore File:

   • A .dockerignore file has been introduced to improve build efficiency by excluding unnecessary files from the Docker context. Specifically, it excludes the target directory, .git directory, and any log or temporary files (*.log, *.tmp).

2. Creation of Dockerfile:

   • A new Dockerfile has been added to facilitate the containerization of the workspace. Key steps include:
     • Utilizing an official openjdk:17-jdk image as the base to ensure compatibility with the Java setup outlined in the pom.xml.
     • Setting the work directory inside the container to /app.
     • Copying the Maven Wrapper (mvnw) and pom.xml files into the container.
     • Copying the project source files from the host to the container's working directory.
     • Ensuring the Maven Wrapper (mvnw) is executable.
     • Running java -version to verify the Java installation.
     • Using the Maven Wrapper to package the application source code without running tests.
     • Moving the packaged .jar file to the root of the application directory.
     • Exposing port 8080 for application accessibility.
     • Launching the application by executing the .jar file with Java.

Rationale for the Changes:

• Containerization: The addition of Docker enables developers to create a consistent development environment, mitigating issues arising from dependencies on local machine configurations.
• Dependency Management: Using Docker ensures that the Java version and Maven configurations align with the project requirements, reducing the risk of version conflicts.
• Efficiency: The .dockerignore file limits the context sent to Docker during build time, optimizing performance and reducing image size.

Potential Risks or Considerations:

• Build Failures: There are ongoing issues with building the application due to Java runtime inaccessibility and unmet Maven dependencies. This indicates a potential mismatch or misconfiguration of the environment within the container.
• Network Access: Dependency management through Maven might require network access to external repositories, which could be a factor in build failures if the network is restricted or dependencies are missing.
• Base Image Compatibility: The selected openjdk:17-jdk image needs to be verified for compatibility with all project dependencies and environmental needs. Alternative images or configurations may be necessary.

Other Relevant Details:

• Additional Configuration Needs: There might be a need to define JAVA_HOME or adjust environment variables to facilitate proper execution of Java and Maven functions within the container.
• Testing and Verification: Despite these changes, persistent issues have been noted, possibly requiring further investigation into network requirements or repository access to resolve Maven build problems.
• Recommendation for Follow-up: Exploring Docker images that include pre-configured environments with both Java and Maven may provide a solution. Additionally, ensuring external repository access and revising Docker settings for resource allocation could help resolve ongoing build issues.