views:

574

answers:

3

Maven's SCM plug-in doesn't appear to provide a "commit" goal. scm:checkin performs a commit AND push. I need to avoid the push.

I'm simply interested in doing an hg commit during install:install. I'm not using the release plugin and don't need it yet. I'm simply working locally in a multi-module environment and want to ensure that my source repository aligns with my Maven locally-installed snapshots for each module. In other words, every time I install a new snapshot of a module, I want the related code committed to hg to make every snapshot directly correlate to an hg revision (or range of revisions when multiple commits occur between snapshots).

A: 

What about setting the connectionUrl on the checkin to a throw-away repository on the local box? So your checkout would come from the "central" repo, but your 'checkin' would go only to the working repository (the commit that you want) and the (apparently) unavoidable push would go to file:///tmp/whocares.

Alternately there's probably a single line of code in the scm plugin to comment out to avoid that push.

Ry4an
Yea, i considered that but thought i'd ask before implementing a workaround. Thanks
nicerobot
A: 

Maven's scm plugin doesn't appear to provide a "commit" goal. scm:checkin performs a commit AND push. I need to avoid the push.

Then the scm plugin is maybe not what you're looking for :)

I'm simply interested in doing an hg commit during install:install. I'm not using the release plugin and don't need it yet.

To be honest, this is a pretty odd usage. While I understand what you described, it doesn't really make sense to me to "sync" a SNAPSHOT with a revision number. Even if you don't commit code between two SNAPSHOT builds, I don't understand how this can this be a problem. In other words, I don't see what is the added value of forcing the commit. And using the release plugin won't solve anything in my opinion.

To summarize, I don't think that the scm plugin will allow you to achieve your goal (at least not without hacking). I don't know if there is mercurial support in Ant but, if there is, maybe you should look in this direction instead (and use the antrun plugin).

Pascal Thivent
The idea is that you can always and easily tell what changes went into a particular snapshot. Useful it, for example, a bug crops in a snapshot days or weeks later, you can go back to the repository to more easily discover what might have been the problem. Also, and consistent with "convention over configuration", if code and comments are documented as to what the change pertains, it becomes a trivial matter to document the changes in a particular snapshot.
nicerobot
A "particular snapshot", there is no such thing. A SNAPSHOT is the latest version from the HEAD. If you want to track things, use fixed version.
Pascal Thivent
Let me put it differently. Whenever a snapshot is created and available, it's assumed that it's ready for consumption (at least in my work-flow) for other projects (though, because it's a snapshot, obviously still under development). It is still useful to know exactly what changes occurred since the last snapshot was built. But, additionally, if i choose to use uniqueVersion=true, then multiple "snapshots" can be available at the same time versioned with a time-stamp and sequence which other projects can refer to specifically instead of just SNAPSHOT. Both cases, this technique is useful.
nicerobot
A: 

The following will bind scm:checkin to the install phase. As long as the repository is a file:// scheme (at least for Mercurial, according to the code), a push is not performed during scm:checkin.

  1. Define properties used in the following steps:

    <properties>
      <message>maven install:install auto-checkin.</message>
      <repository.local>file:///path/to/local/repository</repository.local>
      <repository.type>hg</repository.type>
    </properties>
    

    The <message> can be anything you choose. It isn't ideal to be completely fixed as commits should include meaningful messages as to what changes were made. But, I do believe there should be a standard message included in auto-commits to identify it as such. Just modify the <message> property from step 1. before each install.

  2. This is just a standard scm node for a Maven-based project. Since this is concerned only with a local repository, the URLs are all the same.

    <scm>
      <connection>scm:${repository.type}:${repository.local}</connection>
      <developerConnection>scm:${repository.type}:${repository.local}</developerConnection>
      <url>scm:${repository.type}:${repository.local}</url>
    </scm>
    
  3. This is plug-in that runs during the install phase that performs the commit. It'll simply execute the proper scm checkin based on the definition in step 2.

    <build>
      <plugins>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-scm-plugin</artifactId>
          <version>1.2</version>
          <executions>
            <execution>
              <phase>install</phase>
              <goals>
                <goal>checkin</goal>
              </goals>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </build>
    

One problem is that I receive the following.

DEPRECATED: Binding aggregator mojos to lifecycle phases in the POM is considered dangerous. This feature has been deprecated. Please adjust your POM files accordingly.

I'm looking into how to resolve it but, for now, it works and I'm going with it.

nicerobot
Filed http://jira.codehaus.org/browse/MNG-4504 for "DEPRECATED" message.
nicerobot