CODEWITHSUNDEEP
javamaven-2pom.xml
Dave
Dave

Reputation: 21924

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.

Upvotes: 9

Views: 4843

Answers (5)

SRG
SRG

Reputation: 1579

(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

Upvotes: 4

mcveat
mcveat

Reputation: 1416

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

Upvotes: 4

Pascal Thivent
Pascal Thivent

Reputation: 570295

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 :)

Upvotes: 3

Donal Fellows
Donal Fellows

Reputation: 137557

Without a master pom, there's no technological way to enforce what you ask for (and nor would every project cope with it well in the first place). The only effective way to keep best practices enforced as they evolve over time is by making it someone's job to do the enforcing. You could spread it across many people (e.g., by adding it to their job descriptions) but that tends to leave it getting forgotten because everyone will assume that someone else is doing it. One person, identified by name, and there will be no buck-passing.

Upvotes: 2

bmargulies
bmargulies

Reputation: 100013

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?

Upvotes: 10

Related Questions