Child pages
  • git-workspace-plugin
Skip to end of metadata
Go to start of metadata

This document is a proposed new maven plugin for working with maven and git projects.

Initial usage

Given this git-checkout pom configuration:

Would produce:

The pom.xml in maven-jar-plugin-all basically includes all the modules:

In your IDE you can now open the pom.xml in "maven-jar-plugin-all".

Snapshotting a dependency

Inside the maven-jar-plugin directory you type:

The plugin checks out master of maven-archiver, modifies the referenced version in maven-jar-plugin/pom.xml

Snapshotting a transitive dependency

Inside the maven-jar-plugin directory you type:

The plugin says:

Adding another top-level project

At this point you may want to checkout another top-level project:

Your "src" folder now looks like this:

At this point "plexus-utils" is shared by both "maven-surefire-plugin-all" and "maven-jar-plugin-all".

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.)

Creating a jira/patch for all your changes


git-submodules ... ?

Github support

The plugin should pick up the github.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.



Interesting thoughts in this netbeans feature request:

  • No labels