You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Current »

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

Initial usage

mkdir src
cd src
mvn git-checkout https://git-wip-us.apache.org/repos/asf/maven/maven-jar-plugin.git

Given this git-checkout pom configuration:

<checkoutSources>
	<checkoutSource>org.apache.maven*</checkoutSource>
	<checkoutSource>org.codehaus.plexus*</checkoutSource>
<checkoutSources>

Would produce:

src/maven-jar-plugin-all
src/maven-jar-plugin (trunk)
src/maven-archiver (checked out at tag of effective dependency version)
src/plexus-archiver (checked out at tag of effective dependency version)
src/plexus-interpolation (dependency of maven-archiver)
src/plexus-utils (checked out at tag of effective dependency version)
src/maven-plugin-testing-harness (checked out at tag of effective dependency version)

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

  <modules>
    <module>../maven-jar-plugin</module>
    <module>../maven-archiver</module>
    <module>../plexus-archiver</module>
    <module>../plexus-interpolation</module>
    <module>../plexus-utils</module>
    <module>../maven-plugin-testing-harness</module>
  </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:

mvn git-snapshot maven-archiver

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:

mvn git-snapshot maven-plexus-interpolation

The plugin says:

"plexus interpolation is a dependency of maven-archiver". Choose strategy:
1) Checkout maven-archiver as snapshot too and do transitive dependency upgrade
2) Add overriden dependency in maven-jar-plugin/pom.xml, keep maven-archiver at current version.

Adding another top-level project

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

mvn git-checkout https://git-wip-us.apache.org/repos/asf/maven/maven-surefire-plugin.git

Your "src" folder now looks like this:

src/maven-jar-plugin-all
src/maven-jar-plugin 
src/maven-surefire-plugin-all
src/maven-surefire-plugin 
src/maven-archiver
src/plexus-archiver
src/plexus-interpolation
src/plexus-utils
src/maven-plugin-testing-harness

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

TBD

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.

TBD

References

Interesting thoughts in this netbeans feature request:
http://netbeans.org/bugzilla/show_bug.cgi?id=198781

  • No labels