views:

188

answers:

3

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&lt;/connection&gt;
  <developerConnection>scm:svn:http://buildmachine/org.example/my-artifact/trunk&lt;/developerConnection&gt;
  <url>http://buildmachine/org.example/my-artifact/trunk&lt;/url&gt;
 </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>
A: 

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>
Tom
That is not what I was asking for. I asked for cleaning the pom.xml of artefacts which are being released.
mhaller
Well, if you don't want to distribute the self describing maven descriptor files then simply exclude them from your artifact, e.g. using the <addMavenDescriptor>false</addMavenDescriptor> tag. I can see only three scenarios here: Either someone in your landscape needs to rebuild the artifact, then he should have access to the complete descriptor files, or someone external wants to setup the same project in a different environment and therefore should create its own set of descriptor files from the archetype, or we have an end user who only would need the plain artifact.
Tom
Indeed, i'm talking about scenario 3: an end user who wants to have the artefact, including it's pom.xml (for dependencies, project info etc.), but as he does not need to rebuild the project, there is no need to publish the build-information contained in the pom.xml
mhaller
I still have a hard time to understand the necessity for an end-user to evaluate the pom.xml; he should not be required to do that ... But anyway, you could probably reach your goal by setting up your project as multi-module project and include your private elements in the parent pom.xml only and then use inheritance to make them available to the pom.xml children. The distributed artifact would ship with the child pom.xml only.
Tom
@Tom: this will lead to errors in the user's IDE, since maven would not be able to find the (unpublished) parent pom, which is still referenced in the module's pom.xml due to inheritance.
mhaller
+1  A: 

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.

Zac Thompson
+2  A: 

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.

cetnar
Yes, but see: http://stackoverflow.com/questions/3683543/maven-releaseprepare-overwrites-scm-properties-with-resolved-values
Cornel Masson