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

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.

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.

Yea, I considered that but thought i'd ask before implementing a workaround. Thanks – nicerobot Dec 18 '09 at 21:44.

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

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 Dec 18 '09 at 21:48 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 Dec 19 '09 at 1:27 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 Dec 21 '09 at 3:52.

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. Define properties used in the following steps: maven install:install auto-checkin.

File:///path/to/local/repository hg The 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 property from step 1. Before each install. 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:${repository. Type}:${repository.

Local} scm:${repository. Type}:${repository. Local} scm:${repository.

Type}:${repository. Local} 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.Org.apache.maven.

Plugins maven-scm-plugin 1.2 install checkin 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.

Filed jira.codehaus. Org/browse/MNG-4504 for "DEPRECATED" message. – nicerobot Dec 26 '09 at 0:19.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.