How can I configure Maven to commit to a Mercurial repository when I install:install

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

---

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.

---

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.

---

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