Anonymize pom.xml on release

Question

I've got artefacts which are built and released using Maven. The artefact's original pom.xml contains the usual project information (artifactId, name, etc.) and the dependencies. That's fine. But the pom.xml also includes private information such as the SCM URLs, the names of the developers or a parent-artefact.

Is there any way to tell Maven to generate a pom.xml which is sanitized, so the artefact can be released to public, without destroying the technical relevant information such as the dependencies?

Neither the SCM URLs, nor the list of developers nor the existence of a parent-pom (which is only used for DepMgmt definitions and other meta-stuff) is imho relevant for users of the artefact, so I assume i could be removed from a released pom.xml

The pom.xml both in an repository manager such as Archiva and packaged within the artefact's jar file contain those informations. I assume Maven is just copying the whole thing.

To summarize:

I have:

<project>
   <modelVersion>4.0.0</modelVersion>
   <groupId>org.example</groupId>
   <artifactId>my-artifact</artifactId>
    <scm>
        <connection>scm:svn:http://buildmachine/org.example/my-artifact/trunk</connection>
        <developerConnection>scm:svn:http://buildmachine/org.example/my-artifact/trunk</developerConnection>
        <url>http://buildmachine/org.example/my-artifact/trunk</url>
    </scm>
    <dependencies>
        <dependency>
            ...
        </dependency>
    </dependencies>

I want:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.example</groupId>
    <artifactId>my-artifact</artifactId>
    <dependencies>
        <dependency>
            ...
        </dependency>
    </dependencies>

Answer 1

I don't know perfect solution for your problem, but some things can be done. These are hacks, but they might help.
First, externalize private information from pom (like scm, developer names etc.). For scm metadata it will be:

<scm>
   <connection>${my.scm.connection}</connection>
   <developerConnection>${my.scm.developerConnection}</developerConnection>   
   <url>${my.scm.url}</url>
</scm>

Second, move properties to settings file placing them in a profile. In settings file you can also "hide" your company private repository. If you must share profiles/settings.xml file with other associates, try to use global setting file running mvn -gs path_to_global_settings or prepare common Maven installation with these settings prepared.
Parent pom section unfortunately must stay untouched.

Answer 2

You would create your own archetype for this and release it to the public. Your users then could retrieve the archetype and setup their own project based upon your archetype.

An archetype is a very simple plugin, that contains the project prototype one wishes to create.

To create a new project based on an archetype, one need to call mvn archetype:generate goal, like the following:

  mvn archetype:generate                              \
  -DarchetypeGroupId=<archetype-groupId>              \
  -DarchetypeArtifactId=<archetype-artifactId>        \ 
  -DarchetypeVersion=<archetype-version>              \
  -DgroupId=<my.groupid>                              \
  -DartifactId=<my-artifactId>

Answer 3

The release plugin doesn't have built-in support for this, to my knowledge. Two possibilities come to mind:

Option 1:

• Don't include the pom in your jars - you can control this using the 'archive' parameter to the jar goal. <archive><addMavenDescriptor>false</addMavenDescriptor></archive>
• Write a program to strip out the elements you don't want in your published POM. You'd have to do this between release:prepare and release:perform, which would probably only work if you have support in your SCM for modifying tags after creation, or do the modification under a different tag/branch and then release:perform from there.

I think Option 1 is yucky.

Option 2:

• try to leverage the preparationGoals parameter to the release plugin. If you can write the pom manipulation as maven actions, it might be possible to do it this way.

I think Option 2 is harder.

If none of that works, you'll probably have to use something like release:stage and do the sanitizing by hand, but you'd still want to exclude the POMs from the jar contents.