Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best way to share portions of a Maven pom.xml across unrelated projects?

Our company has defined a number of "best practices" with regard to Maven poms. For example, specifying utf-8 for resource processing, which folders to do filtering on, handling unit tests vs integration tests, and compiler settings.

Right now, these best practices are documented on our company wiki, but when the list of "best practices" changes, these changes are rarely reflected in the project poms, until there is a problem. Human nature being what it is and all....

Is there some way we can provide/enforce these settings and properties via Maven? It's almost like giving every project a parent pom.xml, but I don't want (and can't) have all these projects reference the same parent pom.

We need an approach that will work on developer's machines as well as our Hudson CI server.

like image 495
HDave Avatar asked Nov 11 '10 14:11

HDave


4 Answers

The only maven solution is a common parent. Perhaps if you used a 'released' parent you could do it?

Make a project containing only the parent pom, and run the release plugin, publishing it to your internal repository. Then use that parent as the parent of all your projects, having them download it from your repo instead of finding it by relative pathname?

like image 69
bmargulies Avatar answered Nov 12 '22 01:11

bmargulies


You may build maven project archetype with settings that fulfill your company's best practices. It is rather 'provide' than 'enforce' solution and possibly may be not enough (depending on what those best practices really are). http://maven.apache.org/guides/mini/guide-creating-archetypes.html

like image 34
mcveat Avatar answered Nov 12 '22 01:11

mcveat


(this is an old thread, i'm just adding this information for reference)

For dependencies, you can use "dependencyManagement" import bloc (but it'll work only with dependencies and not properties, and so on).

Just have a "library" pom defining various dependencies as usual (with their exclusions and specific versions).

Then in the main pom of your project, you'll import that dependency section into your "dependencyManagement" section : every dependencies defined in the library pom will be imported. And, moreover, every versions defined in this dependencyManagement will be always used by Maven (Maven won't take another version than the one defined in the dependencyManagement). This is nearly mandatory in order to manage your classpath if you have various projects relying onto the same libraries set.

In the pom of your main project, import the library pom like this :

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.mycompany.mylibrary</groupId>
            <artifactId>mylibrary-artifact</artifactId>
            <version>mylibrary-version</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        ...

Check online maven documentation

like image 21
SRG Avatar answered Nov 12 '22 00:11

SRG


It's almost like giving every project a parent pom.xml, but I don't want (and can't) have all these projects reference the same parent pom.

I'm not saying to necessarily put everything in a parent POM but in a corporate environment, it's really a good idea to have a top-level corporate POM (as illustrated in the section 3.6.2.2. Multi-module Enterprise Project of the maven book), with its own release cycle.

But this won't be enough to enforce anything and my suggestion would be to look at the Maven Enforcer Plugin that offers existing rules but also allows to write your own custom rules using the maven-enforcer-rule-api. I can't comment how far you can go with custom rules though. Anyway, I highly recommend this plugin. If you're not using it yet, it's definitely time to start :)

like image 25
Pascal Thivent Avatar answered Nov 12 '22 02:11

Pascal Thivent