patrick schneider

Because of SCM-229, you no longer need to specify the <scm/> stuff in your POM. Because anything you checkout from Perforce always knows from where in the source it originated (via the ClientSpec), Maven can now dynamically determine where this code is, what should be labeled (during release), and won’t complain if this value is completely wrong.

This last point should be taken seriously though — putting a real value in the <scm/> element could lead to confusion. For my projects, I use an SCM section that looks like this:

...
<scm>
  <connection>scm:perforce://fake-scm-paths</connection>
  <developerConnection>scm:perforce://see-SCM-229</developerConnection>
</scm>
...

The point being that this is clearly a fake SCM location, but also points you to the reason why (SCM-229). This is especially useful when branching — you don’t need to update the SCM location in order to release your project from a branched location in source control.

Oh — one important thing to note is which version of the release plugin you are using. SCM-229 was fixed in version 1.0-beta-4 of maven-scm-provider-perforce, which is used in the 2.0-beta-6 version of the maven-release-plugin. So if you are not already explicitly declaring the versions of your plugins (you should be!), you’ll need to ensure your POM has this info:

<build>
  ...
  <plugins>
    ...
    <plugin>
      <artifactId>maven-release-plugin</artifactId>
      <version>2.0-beta-6</version>
    </plugin>
    ...
  </plugins>
  ...
</build>

Enjoy

We have an internal Maven repository at my company. This allows us to have an official repo of “approved” artifacts that developers can use. (For example, GPL’ed projects might not be legal to use for our purposes.)

Anyway, we use a script to pull down artifacts from the official Maven repository (http://repo1.maven.org/maven2/). However, the script does not overwrite, and sometimes metadata files are duplicated. The resulting directory listing for an artifact might look like this:

$ ls -1
1.0
1.0-rc1
maven-metadata.xml
maven-metadata.xml.1
maven-metadata.md5
maven-metadata.md5.1
maven-metadata.sha1
maven-metadata.sha1.1

Obviously fixing the script to overwrite would solve the problem of these “.1″ files. But, I was curious as to how I could easily move the “.1″ files to their appropriately named counterparts. My newfound love for xargs made me think that I could do this in one cool command-line statement. Here’s what I came up with:

ls -1 *.1 | sed 's/.1//' | xargs -i mv {}.1 {}

Broken down:

1. I pass the “-1″ flag to ls, which tells it to print each item on a separate line. I filter ls to only show files that match the “*.1″ pattern.

2. Each line of output from ls is piped into sed, which just simply substitutes nothing for “.1″. We have constructed the desired file name.

3. Now, I can pipe each of these desired file names into xargs, and use the -i flag to substitute the standard input to the {} token.

Maybe there’s a completely obvious way to do this that I haven’t run across, but, like I said — newly discovered love for xargs, and everything looks like it can be piped into it