Final mini project

Final Exercise

Final mini project

This final exercise lets you repeat the full beginner workflow without reading the earlier lessons line by line.

Create and distribute a tiny assignment called shape-workshop with:

  • one distribution named WS1
  • at least two generated repositories
  • one placeholder-based template
  • one individualization.json with two simple variation axes
  • one successful real distribution
  • one verified result using state files and overview commands

Success criteria

By the end of the exercise, you should have:

  • a new origin repository
  • a configured distribution
  • a working individualization file for Shape and Color
  • generated individuals.json
  • generated remotes.json
  • a verified remote result on your GitLab target

Before you start

Reuse the host alias you configured earlier in the course.

Before you begin the exercise, make sure you have:

  • one GitLab group or namespace where you may create the new repositories
  • one concrete groupId for that target
  • at least one real account you can use to test member assignment

If you only have one safe test account, reuse it on two lines of the member input — each line becomes its own group and generated repository.

Build a minimal assignment around the placeholders $Shape$ and $Color$.

Possible variation values:

  • Circle
  • Square
  • Triangle

Possible color values:

  • Red
  • Blue
  • Green

Suggested file idea

Your template can be as small as this — put the placeholders into the file name too, for example src/$Color$$Shape$.java:

public class $Color$$Shape$ {
    public String label() {
        return "$Color$ $Shape$";
    }
}

A tiny README is enough.

Suggested working order

Complete the following without copy-pasting the earlier lesson text line by line:

  1. create the project directory
  2. run divekit init with the distribution name WS1
  3. create one tiny placeholder-based source file
  4. review config.json so it points to your real host alias and your real groupId — the default naming pattern already keeps the UUID visible
  5. check with divekit dev which placeholders still need individualization, then scaffold the file with divekit dev --write-individualization
  6. review or refine individualization.json so it contains Shape and Color as object IDs, each with its own kinds
  7. run divekit dev again
  8. run divekit doctor
  9. provide your test member with divekit members, or enter it when divekit distribute asks
  10. optionally run divekit distribute -d WS1 --provider local
  11. run divekit distribute -d WS1
  12. inspect individuals.json and remotes.json
  13. run divekit overview -d WS1

Verify your result

Before you mark the exercise as done, verify all of the following:

  • divekit doctor does not show a blocking setup problem
  • divekit dev does not show unresolved placeholders you still need to define
  • if you used divekit distribute -d WS1 --provider local, the generated local result looked correct
  • divekit distribute -d WS1 creates the expected repositories
  • individuals.json contains every UUID you planned
  • individuals.json records a concrete choice for both Shape and Color
  • remotes.json records every created remote repository
  • your test member is visible on the created repositories in GitLab
  • divekit overview -d WS1 matches the visible result in GitLab

If one of these checks fails, do not start over immediately. Reuse the troubleshooting order from the previous lesson.

Check

Strong answer
Setup files such as config.json and individualization.json are the files you review and edit to define the rollout. State files such as individuals.json and remotes.json are generated by Divekit and record what the rollout actually produced.
Strong answer
divekit doctor is often the clearest answer because it reveals blocking setup problems before the real rollout. divekit dev adds confidence by confirming that placeholders are fully defined, and divekit distribute -d WS1 --provider local can show a realistic result without touching the real GitLab target.
Strong answer
Start with individuals.json if the UUID seems linked to the wrong generated individual or the wrong variation choices. Inspect remotes.json first if the problem is which remote repository that UUID ended up in. In practice, checking both is often the fastest way to confirm the full mapping.
Strong answer
It should confirm that there are no unresolved placeholders left for either Shape or Color.

If all checks pass, you have completed the beginner course: from a plain project folder to a verified, individualized distribution.

Clean up

The exercise repositories have served their purpose — delete them from the shared GitLab instance:

divekit purge -d WS1

Divekit lists the repositories in the target group, shows a deletion plan, and asks for confirmation.

Remember the warning from the troubleshooting lesson: the plan covers everything in the target group, not only what this distribution created. Read it before you confirm — if it lists more than your WS1 exercise repositories, answer No and check which group you are targeting.