...
As surefire is checked out, it will attempt to check out the appropriate version of plexus-utils.
At this stage, several interesting things may happen, depending on a user settings, see the next section.
Branch/branchless strategy
I the workspace.userBranches=true setting is active (normally from settings.xml), the workspace plugin will create distinct branches
in shared module to separate activity within the different workspaces. Otherwise it will try to operate with a single point of change:
When a dependency is requested to change scm version, the following procedure will be followed (with plexus-utils being the sample dependency):
A) User has workspace.useBranches=true in settings.xml:
1. Current changes (if any) will be committed to the active branch with a commit message of "workspace plugin autocommit"
2. A branch with the current workspace name will be created in plexus-utils if no such branch exists.
3. Branch is updated to point to the correct place.
B) User has no workspace.useBranches setting:
1. Plexus-utils is unmodified (we did not do any changes throuh maven-jar-plugin-all) -> correct version is checked out (This does not make sense, we must make a branch or checkout detached. Detached head is too confusing for n00bs. Consider only working in "trunk" mode when branchless)
2. Plexus-utils has modifications at current checkout -> "git-checkout" downloads the remaining repository sources,
creates maven-surefire-plugin-all/pom.xml and then resets any modified repositories to their pre-git-checkout state (effectively this aborts the "git-checkout" and leaves all the repos unchanged.)
...
The plugin should pick up the $GITHUB environment variable or similargithub.account settings from settings.xml (or maybe some environment if there is a convention). When resolving a repository, it will check if there is an appropriate fork of the project on the given github account. If such a fork exists it will be cloned as origin and the authorative repository will be added as for instance "apache" (based on hostname of origin, probably). In such a case, the project can always be pushed to origin, since that represents the github fork.
...