Course Enrollment and Progress Manager

1. Project setup and domain model

Scenario: you are building the backend logic behind a learning platform's enrollment system — entirely as a local, Maven-based Java console application (no database, no network). Set up a Maven project (mvn archetype:generate) organized into packages by feature: com.visaspark.enrollment.model (Course, Learner, Enrollment), com.visaspark.enrollment.exceptions, and com.visaspark.enrollment.app (the Main entry point). Define Course and Learner as encapsulated classes (private final fields, constructors validating their inputs, and only the getters that are actually needed).

• The project builds with `mvn compile` and has the three-package structure described above
• Course and Learner have private, final fields with no public setters for identity-like fields (id, title/name)
• Constructors validate their inputs (e.g. reject a blank title or name) and throw a specific, custom exception on invalid input

2. Enrollment, composition, and an interface with two implementations

Implement an Enrollment class that composes a Learner and a Course (a field, not inheritance) plus a mutable set of completed lesson IDs and a completion-percentage calculation. Define a Progressable interface (e.g. a method like double completionPercentage()) and implement it on at least two genuinely different classes (Enrollment itself, and a second, distinct type such as a Milestone or Certification that also tracks a percentage a different way) so a single polymorphic method can report progress across both without branching on type.

• Enrollment composes a Learner and Course by reference, not by extending either class
• A Progressable interface exists and is implemented by at least two structurally different classes
• A method exists that computes/reports progress across a mixed List<Progressable> using only the interface, with no instanceof checks

3. Structured exceptions and validation

Define a small exception hierarchy (e.g. an abstract EnrollmentException extends RuntimeException, with concrete subclasses like DuplicateEnrollmentException and InvalidLessonReferenceException) and use it to reject invalid operations: enrolling the same learner in the same course twice, or marking a lesson complete that doesn't belong to the enrolled course. Every validation failure must throw the specific, correct exception subtype — never a generic RuntimeException or IllegalArgumentException standing in for a case that has its own named type.

• At least two distinct, purpose-specific exception subclasses exist, both extending a shared base exception
• Enrolling a learner in a course they're already enrolled in throws the specific DuplicateEnrollmentException
• Marking a lesson complete for a lesson not belonging to the enrolled course throws the specific InvalidLessonReferenceException

4. Equality, hashing, and a Stream-based summary

Implement equals() and hashCode() correctly and consistently for Enrollment (two Enrollments should be equal if they reference the same learner and course, regardless of completed-lesson state) — and add at least one HashSet or HashMap operation in the application that depends on this being correct (e.g. deduplicating a list of Enrollments). Then use the Stream API to compute at least one derived summary across a List<Enrollment> — for example, the average completion percentage across all of one learner's enrollments, or the count of fully-completed enrollments.

• equals()/hashCode() are both overridden on Enrollment, consistently, based on learner + course identity
• At least one HashSet or HashMap operation in the app demonstrably relies on this equals()/hashCode() pair being correct
• At least one Stream pipeline (filter/map/reduce or a collector) computes a real derived summary from a List<Enrollment>

5. JUnit tests and a console entry point

Add a JUnit 5 test suite (src/test/java, mirroring your main package structure) covering: successful enrollment, the duplicate-enrollment rejection, the invalid-lesson-reference rejection, correct completion-percentage computation, and the equals()/hashCode() contract. Finish Main.java as a deterministic console entry point that builds a small, fixed set of courses/learners/enrollments, performs a few operations (including at least one that intentionally triggers and catches a custom exception), and prints a human-readable summary.

• At least 6 JUnit tests exist, covering both success and failure/rejection cases
• `mvn test` runs the full suite successfully with zero failures
• Main.java runs deterministically end to end via `mvn exec:java`, printing a real summary and demonstrating at least one caught, handled custom exception