4

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>
Robert Munteanu
  • 67,031
  • 36
  • 206
  • 278
mhaller
  • 14,122
  • 1
  • 42
  • 61
  • By release, do you mean using the Maven Release Plugin? – Pascal Thivent Nov 20 '09 at 14:15
  • Yes, maven-release-plugin. Removing: well, they contain development-internal information, such as the hostname of the build server. Customers don't need to know the hostname of my buildserver. In OSS projects, this may be irrelevant, but in corporate environments, this is a "security" issue. (yeah i know ...) – mhaller Nov 20 '09 at 14:33
  • Another question: do your customers use your artifacts as maven dependencies (in which case, OMG, they know the hostname of archiva :D)? – Pascal Thivent Nov 20 '09 at 16:40
  • Yes they do. I'd like to have the 'public' pom's clean. I dislike distributions poisened with internal stuff, e.g. when projects forget to remove their ".svn" hidden folders and alike. It should be as clean as possible, as it's a product. For an OSS project or hobby project, i wouldn't care at all. – mhaller Nov 20 '09 at 19:29
  • It worth to mention that for open source project, information about developers, scm, issue tracker, etc is very important. It makes it easier to communicate and also opens a gate for additional features. See, for example workspace materialization supported by m2eclipse. http://www.jroller.com/eu/entry/maven_project_materialization – Eugene Kuleshov Dec 06 '09 at 00:07

3 Answers3

3

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
  • 9,357
  • 2
  • 38
  • 45
  • Yes, but see: http://stackoverflow.com/questions/3683543/maven-releaseprepare-overwrites-scm-properties-with-resolved-values – Cornel Masson Sep 10 '10 at 14:39
1

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
  • 12,401
  • 45
  • 57
0

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
  • 424
  • 4
  • 9
  • That is not what I was asking for. I asked for cleaning the pom.xml of artefacts which are being released. – mhaller Nov 21 '09 at 12:07
  • 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 Nov 22 '09 at 05:20
  • 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 Nov 22 '09 at 10:52
  • 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 Nov 23 '09 at 04:52
  • @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 Nov 30 '09 at 09:24