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.
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?
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
(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
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 :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With