Why D287 Feels Unfinished (And Why That's Not a You Problem)

The study material and the performance assessment were assembled by different people. ZyBooks and the Spring in Action textbook explain Spring in general, while the rubric grades specific edits to a specific starter app. Students frequently report instructor videos marked "coming soon" and a Part H demo that covers only one of its three requirements.

That mismatch explains most of the frustration, and it means slow progress is not a sign you lack aptitude. You are inheriting a half-finished codebase, which is a real workplace scenario, just a poorly documented one. Reframing the project as "someone quit mid-sprint and left me their mess" makes the inconsistent formatting and dead code easier to tolerate.

Timelines vary. A steady pace lands most students between two and four weeks, while accelerators who keep a guide open in a second tab finish in four to ten days. Send-backs citing build failures that never reproduce on your machine usually trace to a Java or Spring Boot version mismatch rather than your logic.

IntelliJ, the JetBrains License, and the GitLab Pipeline

Start with tooling, because this is where the first wall appears. Download IntelliJ IDEA Ultimate and activate the student license. A wgu.edu address works directly now, though the older route accepted unofficial transcripts as an "Official Document" upload.

Getting your repository requires a pipeline run rather than a clone button:

  1. Sign in to the WGU GitLab environment with your WGU credentials.
  2. Open Students, then D287 Java Frameworks, then Build, then Pipelines.
  3. Run the pipeline and create the student environment, then wait up to ten minutes before assuming it failed.

Once the repo exists, create a working branch before touching anything. Both main and students-run-this are protected, and pushes there fail with a branch name error. Clone with HTTPS from your working branch; a 403 usually means a stray tilde at the end of the pasted URL, so paste with Ctrl+Shift+V. When IntelliJ asks for a token, generate one under Settings and Access Tokens with read and write repository scopes.

Mac users can ignore the Parallels advice. IntelliJ runs natively on Apple silicon, and your app serves at localhost:8080 once a Spring Boot run configuration points at the main application class.

Reading the Starter Project Like a Codebase, Not a Textbook

Open the project expecting to read code, not study it. The folders map onto MVC: domain holds entities, repositories handle database access, service and its implementation files hold logic, validators enforce rules, controllers route requests, and templates plus static/css build what users see. The annotations doing the work are @Entity, @Repository, @Service, @Controller, @Autowired, @GetMapping, and @PostMapping.

A handful of files cause most "it won't run" moments. BootStrapData.java seeds sample data, application.properties controls database behavior, and pom.xml pins your Java and Spring versions. Check those three before rewriting logic.

For tasks A and B, the README already exists, so treat it as your change log. Note each edit by file name, line number, and short description under the matching rubric letter, commit and push after every letter from C through J, and leave the Outsourced part code in place even if your shop never uses it. Removing base code adds risk with no upside.

Parts C Through F: Shop Theme, About Page, Sample Inventory, and the Buy Now Button

Part C only asks you to rename the shop and adjust titles and headers in mainscreen.html. Do not hardcode products into that table, since the controller already populates it from the repository. Part D adds about.html plus a controller with a @GetMapping, and white label errors here almost always mean a missing or misspelled mapping.

Part E is where most send-backs originate. Add five products and five parts in BootStrapData.java, wrapped in a check that both repository counts equal zero so restarts do not duplicate everything. If duplicates already exist, delete them at localhost:8080 or switch the ddl-auto setting to create-drop, restart, and change it back to update.

Part F requires a POST form to /buyProduct with a hidden product id field. The controller reads that id with @RequestParam, looks it up with findById, decrements inventory, and saves. Two simple templates, one for success and one for failure, keep the messaging clear, and @Transactional lets a single @GetMapping handle the flow. Selling a product lowers product stock only; parts never return to inventory.

THE STARTER APP IS MVC — READ IT, DON'T STUDY IT templates/ + static/css what users see @Controller @GetMapping @PostMapping @Service logic, impls @Autowired @Repository database access @Entity domain H2 / MySQL BootStrapData seeds sample data Check BootStrapData.java, application.properties and pom.xml first — they cause most "it won't run" moments. PARTS G AND H — THE VALIDATION PATH Thymeleaf form the min and max inputs Part.min / Part.max one method on Part.java BindingResult rejectValue(...) Error text on screen the property node in the form THE THREE PART H MESSAGES 1 · Below the minimum when adding or updating a part 2 · Above the maximum the same check, inverted 3 · Product drops a part lives in EnufPartsValidator A validator that blocks the save but shows no text is a missing error binding in the form.
Figure 1. The D287 starter app as an MVC request flow, with the annotations that do the work, the Part G/H validation path, and the three Part H messages.

Parts G and H: Min/Max Inventory, Custom Validators, and Error Display Logic

Part G begins in Part.java, where you add minimum and maximum inventory fields along with a matching constructor, getters, and setters. Update BootStrapData.java so your five sample parts carry real min and max values, then add both inputs to InhousePartForm.html and OutsourcedPartForm.html by copying the existing field pattern. Rename the H2 database file in your user home directory and change the matching name in application.properties, or Hibernate will throw DDL errors on startup.

The validation logic is simpler than the instructions suggest. A method on Part.java that returns true when inventory falls between the min and max gives you one check to call from both part controllers. Students commonly enforce it with BindingResult and rejectValue instead of a custom annotation, and both routes pass evaluation.

Part H adds three specific messages: inventory below the minimum when adding or updating a part, inventory above the maximum, and a product update that would drop an associated part below its minimum. That third condition lives in the existing EnufPartsValidator, where the check becomes the part inventory minus one compared against its minimum.

The most common Part H complaint is a validator that blocks the submission but never displays text. That is almost always a missing error binding in the Thymeleaf form rather than broken logic, so inspect the form markup for the property node tied to your field. A whitelabel error page when updating a product points to an unhandled exception or a missing mapping. Test inventory landing exactly on zero too, since many students catch negatives but miss zero.

Parts I and J: Unit Testing, Readme Documentation, and Final Submission Discipline

Part I is short. Add two tests to PartTest for minimum and maximum inventory, using the @Test annotation and assertEquals in the same shape as the tests already in that file. Pick arbitrary values, cover both in-house and outsourced parts, and move on. Part J asks you to delete unused validator classes, and IntelliJ shows a usage count when you open each file.

Documentation carries real weight here. Your README should record every change by file name, line numbers, and a short description, filed under the matching rubric letter. Some students paste full code blocks and others write one line per edit. Either works, but extra detail is safer than too little, and committing after each letter keeps the repository graph readable.

Then assemble the submission package:

  • The project ZIP.
  • A PDF of your repository graph from GitLab under Code.
  • The repository URL.

Before zipping, run mvn clean install and mvn spring-boot:run to confirm the build matches the evaluator environment. Check that your Java and Spring Boot versions in pom.xml line up with the recommended setup, and confirm your sample inventory loads on a fresh run.

An Actionable 7-Step Milestone Routine to Pass D287 in Under 2 Weeks

  1. Days 1-2: Set up IntelliJ, activate the license, run the pipeline, create your working branch, clone, and get the app serving at localhost:8080.
  2. Day 3: Map the folder structure and watch the course webinars for tasks D through G, noting which file each one touches.
  3. Days 4-5: Complete C, D, and E, then verify your five products and five parts appear after a restart.
  4. Day 6: Build the Buy Now button, its controller, and the two result templates. Test both outcomes.
  5. Days 7-9: Work G and H together, since the same validation logic satisfies the end of G and most of H. Fix error display before moving on.
  6. Day 10: Add the Part I tests, delete unused validators for Part J, and finish the README letter by letter.
  7. Days 11-14: Run the completed project video as a checklist, rebuild from a clean clone, export the ZIP and repository graph, then submit with time left for a revision request.

References

Sikandar Ali - Academic Consultant
Written by Sikandar Ali

Sikandar Ali is a skilled academic consultant with expertise in research methodology and essay structure. With over 10 years of experience, he helps students develop critical thinking and writing skills for academic success.