Development: Add Atlas Profile with optionally autowired Atlas Java API

[ole-ve]

Breaking Change: atlas profile needs to be enabled after merging this PR. Otherwise, all atlas-related functionality is disabled (client & server).

Checklist

General

• I tested all changes and their related features with all corresponding user types on a test server.
• I chose a title conforming to the naming conventions for pull requests.

Server

• Important: I implemented the changes with a very good performance and prevented too many (unnecessary) and too complex database calls.
• I strictly followed the principle of data economy for all database calls.
• I strictly followed the server coding and design guidelines.
• I documented the Java code using JavaDoc style.

Changes affecting Programming Exercises

• High priority: I tested all changes and their related features with all corresponding user types on a test server configured with the integrated lifecycle setup (LocalVC and LocalCI).
• I tested all changes and their related features with all corresponding user types on a test server configured with Gitlab and Jenkins.

Motivation and Context

To allow starting Artemis without atlas, we would need to optionally autowire the atlas Java APIs introduced in !9752.

Description

For this, we need to add a new Spring profile specific to atlas (PROFILE_ATLAS) and pass in the atlas Java APIs as Optionals to the Spring components constructor. Depending on whether the call is crucially required, an ApiNotPresentException is thrown. This, for instance, is not required when updating the competency progress (asynchronously).

I have tested the following reasons for data inconsistencies:

• Initials start without atlas

  • Still creates the DB tables, but Java migrations are skipped.

• Task created

  • Competencies linked, learning path generated for user, task evaluated.
  • Without profile: Task deleted.
  • With profile: Restart without issues, no residuals in the learning path.
    • Competency progress, however, remains.
    • Atlas entities still exist in the DB.

• Lecture with unit created

  • Competencies linked, learning path generated for user.
  • Without profile: Lecture deleted.
  • With profile: Restart without issues, no residuals in the learning path.
    • Atlas entities still exist in the DB.

• With profile: Course created

  • Linked lecture units and learning path enabled, student participated, path generated, tasks evaluated.
  • Without profile: Course deleted.
  • With profile: All related objects removed from the DB.

Steps for Testing

These changes need to be tested locally OR on test server 3.

1. Start the server with the Atlas profile enabled ("atlas" should be part of your run config, e.g. Artemis__Server_.xml), changes as part of this PR.
2. Create a course with learning paths enabled.
3. Create any resource that are related to atlas (exercises, lecture units, competencies, etc.)
4. Participate in the course as a student, generate the learning path and create participations for lecture units/exercises
5. Restart the server without the Atlas profile by removing it from your run config (see step 1)
6. Delete the lecture units and exercise
7. Start with Atlas profile enabled and verify that everything works as expected
8. Restart without atlas profile
9. Delete the course
10. Restart with atlas profile. Verify that everything still works

Testserver States

Note

These badges show the state of the test servers.
Green = Currently available, Red = Currently locked
Click on the badges to get to the test servers.

Review Progress

Code Review

• Code Review 1
• Code Review 2

Manual Tests

• Test 1
• Test 2

Summary by CodeRabbit

Summary by CodeRabbit

• New Features

  • Integrated a new "Atlas" competency management system that enhances course management functionalities. Instructors will now see additional options for managing competencies and learning paths.

• Documentation

  • Updated the setup guides and configuration instructions to reflect the inclusion of the Atlas profile in the default deployment.
  • Enhanced the user documentation for various services to clarify the new profile configurations and their implications.

• Refactor

  • Improved overall system robustness and error handling by conditionally enabling features, ensuring a smoother user experience.
  • Updated several services and resources to handle optional dependencies, enhancing error handling and preventing potential runtime exceptions.

These enhancements aim to provide a more streamlined and feature-rich course management experience for end-users.

[AjayvirS]

Tested locally, works as expected with Atlas disabled

[coolchock]

tested locally, works as described

[cremertim]

tested loclly according to the testing steps. Works as expected

[tobias-lippert]

I think I found one unintended change.
Otherwise, I just have two questions.

[tobias-lippert]

Thanks for answering my questions. LGTM now.

[az108]

Code LGTM 👍

[MaximilianAnzinger]

The coverage fails. There seems to be one new class that has 0 Coverage and thus it fails the complete verification. Please adjust the threshold.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

gradle/jacoco.gradle (1)

2-2: Consider tracking coverage improvement goals.

The TODOs indicate ambitious targets (90% instruction coverage, 0 class coverage), but there's no clear timeline or tracking mechanism. Consider:

1. Converting these TODOs into tracked issues
2. Creating a gradual improvement plan with milestones

Would you like me to help create a template for tracking these coverage improvement goals?

Also applies to: 4-4

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 976d1f5 and 071855e.

📒 Files selected for processing (1)

• gradle/jacoco.gradle (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms (8)

• GitHub Check: Call Build Workflow / Build and Push Docker Image
• GitHub Check: Call Build Workflow / Build .war artifact
• GitHub Check: Codacy Static Code Analysis
• GitHub Check: client-tests-selected
• GitHub Check: server-style
• GitHub Check: client-tests
• GitHub Check: server-tests
• GitHub Check: Analyse

🔇 Additional comments (2)

gradle/jacoco.gradle (2)

3-3: LGTM! Gradual improvement in code coverage thresholds.

The incremental increases in coverage thresholds for both aggregated (70) and core module (18) demonstrate a commitment to improving code quality through better test coverage.

Also applies to: 11-11

---

213-261: LGTM! Well-structured coverage reporting with security considerations.

The implementation demonstrates good practices:

• Secure XML parsing without DOCTYPE
• Clear error handling and reporting
• Informative coverage statistics output

[ole-ve]

PR is ready to merge, but depends on admins adding the atlas profiles to run configs on

• remaining test servers
• staging
• production

Until then, this PR is blocked.

[HawKhiem]

Tested locally. Works as described