basepom / basepom Goto Github PK

All the base POMs in the world.

License: Apache License 2.0

Makefile 100.00%

basepom's Introduction

The BasePOM project - "All the BasePOMs in the world"

The BasePOM project aims to make using Apache Maven as a build tool painless. It provides a set of well known plugins for Apache Maven with an opinionated base configuration and a number of configuration options. It is aiming at Java projects but can easily be extended for other languages that are supported by Apache Maven.

It provides base configurations for unified, organization-wide build setups and supports simple project setups and complex Multi Module project use cases.

BasePOM and its private predecessors have been in use in many companies and open-source projects since 2010.

Core features of BasePOM:

Opinionated configuration. BasePOM Parent POMs configure Maven Plugins with reasonable defaults

Property based customization. BasePOM Parent POMs expose a number of properties that can be customized in Child POMs or from the command line

Profile activation. BasePOM Parent POMs contain a number of profiles that activate under specific conditions and customize build steps or activate specific plugins

Policy modifications. Any aspect of a BasePOM Parent POM can be customized through Policy POMs

Full documentation and user guide

Building, deployment and releasing

Building and deployment

# install BasePOMs locally
% make install

# deploy BasePOMs to remote (snapshot) repository
% make deploy

Create and deploy documentation

# create local docs in docs/target/site
% make docs

# deploy documentation to the basepom.org site
% make deploy-docs

Create a release

# create a release to OSS
% make release

The BasePOM code is licensed under the Apache Software License v2 (ASLv2)

basepom's People

Contributors

Stargazers

Watchers

basepom's Issues

add scm-publish plugin

Plugin to check dependency scopes

We periodically run into a situation where a developer only uses Guava in their tests, so it seems reasonable to add a guava dependency with <scope>test</scope>. But then their application fails at startup because many of their transitive dependencies rely on Guava at runtime (and the local test scope overrides the transitive compile scope). It would be nice to alter this dependency resolution behavior in Maven itself, but that was suggested 8 years ago and didn't seem to go anywhere. I used Guava as an example, but we've run into this issue with a variety of different libraries.

This issue is especially annoying for a few reasons:

the error manifests itself as a NoClassDefFoundError for a third party class, so our developers usually suspect a version conflict and waste a bunch of time before escalating to someone who is aware of this Maven gotcha
the dependency is on the classpath at test time, so no amount of testing will catch this issue at build time
knowing whether it's safe to add <scope>test</scope> to a dependency is non-trivial, it requires a lot of intuition and tribal knowledge

What would be helpful for us is a plugin that checks all test-scoped dependencies to see if they appear anywhere else in the dependency tree at compile or runtime scope (taking exclusions into account) and optionally failing the build if any violations are found. Do you know of an existing plugin that does this? If not, I can try to write one. And do you think it would be appropriate to include a plugin like this in basepom?

Use nexus-staging-maven-plugin for release deployments in oss

The nexus-staging-maven-plugin is the recommended mechanism for releasing to Sonatype OSSRH.

While the traditional Maven deploy-to-repo approach works too, it basically forces you to control the staging process via the (somewhat annoying) web interface. The staging plugin makes this a bit easier and more convenient. Since the OSS basepom is specifically intended for OSS releases, wouldn't it make sense to include it in the POM so it's part of the release process (for non-SNAPSHOTs)?

Provided Scope Configuration Inquery Reguarding dependency-versions-check-maven-plugin

I'm using Basepom v51 and I'm finding some version failures in my builds even though I believe I am packaging them correctly. I lean toward my lack of understanding of packaging, but it might be a simple configuration issue. Both the application and the library rely on a near default basepom configuration.

Application Build Failure Log Output (group and artifact ids redacted):

[INFO] --- dependency-versions-check-maven-plugin:3.2.0:check (basepom.default) @ medium-tests ---
[INFO] Checking direct dependencies for 'test' scope, reporting only conflicts
[ERROR] org.projectlombok:lombok: 1.18.24 (direct) - scope: provided - strategy: default
       1.18.24 expected by c.a.c.h.s:a, *c.a.c.h.s:m-t*
       1.18.26 expected by c.a.d.g:d-t-e, c.a.d.g:s-t-e

c.a.c.h.s:a dependency tree:

[INFO] -----------< c.a.c.h.s:a >------------
[INFO] Building a 0.0.16-SNAPSHOT                                       [2/3]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- maven-dependency-plugin:3.4.0:tree (default-cli) @ a ---
[INFO] c.a.c.h.s:a:jar:0.0.16-SNAPSHOT
...
...
[INFO] +- org.projectlombok:lombok:jar:1.18.24:provided
[INFO] \- com.google.code.findbugs:findbugs-annotations:jar:3.0.1:provided

c.a.c.h.s:m-t has a dependency on c.a.c.h.s:a
c.a.c.h.s:m-t also has a dependency on c.a.d.g:s-t-e

The library c.a.d.g:s-t-e dependency tree:

[INFO] ----------< c.a.d.g:s-t-e >----------
[INFO] Building s-t-e 1.0.0-SNAPSHOT                        [7/11]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- maven-dependency-plugin:3.4.0:tree (default-cli) @ s-t-e ---
[INFO] c.a.d.g:s-t-e:jar:1.0.0-SNAPSHOT
...
...
[INFO] +- org.projectlombok:lombok:jar:1.18.26:provided
[INFO] \- com.google.code.findbugs:findbugs-annotations:jar:3.0.1:provided

A simple fix is to simply bump my application code (c.a.c.h.s:a) to rely on the newer version. This is what I will be doing, but I don't want to impose my build time dependency on version 1.18.26 of lombok in my library on the applications that use my library.

I was under the impression that the maven provided scope is the correct way to do this, so when the build fails during dependency-versions-check-maven-plugin, I can tell I'm lacking understanding.

I'm not sure if the version check plugin should be configured differently, or if I should change my packaging strategy in my library.

release preparationGoals surprisingly includes install

Currently, release plugin preparationGoals is set to clean install. This means running release:prepare by default will mutate the local repository and (locally) publish artifacts. Normally, you only expect this to happen on the release:perform step. It would be nice to consider whether this behavior is still good, and at least make it configurable, or take the default clean verify.

add the buildplan plugin

mvn fr.jcgay.maven.plugins:buildplan-maven-plugin:list

Inject Api Classes are failing builds again

[WARNING]   javax.inject.Inject
[WARNING]   javax.inject.Named
[WARNING]   javax.inject.Provider
[WARNING]   javax.inject.Qualifier
[WARNING]   javax.inject.Scope
[WARNING]   javax.inject.Singleton
[WARNING] Found duplicate classes/resources in compile classpath.
[WARNING] Found duplicate and different classes in [jakarta.inject:jakarta.inject-api:1.0.5, javax.inject:javax.inject:1, org.glassfish.hk2.external:jakarta.inject:2.6.1]:
[WARNING]   javax.inject.Inject
[WARNING]   javax.inject.Named
[WARNING]   javax.inject.Provider
[WARNING]   javax.inject.Qualifier
[WARNING]   javax.inject.Scope
[WARNING]   javax.inject.Singleton
[WARNING] Found duplicate classes/resources in runtime classpath.
[WARNING] Found duplicate and different classes in [jakarta.inject:jakarta.inject-api:1.0.5, javax.inject:javax.inject:1, org.glassfish.hk2.external:jakarta.inject:2.6.1]:
[WARNING]   javax.inject.Inject
[WARNING]   javax.inject.Named
[WARNING]   javax.inject.Provider
[WARNING]   javax.inject.Qualifier
[WARNING]   javax.inject.Scope
[WARNING]   javax.inject.Singleton
[WARNING] Found duplicate classes/resources in test classpath.

I think this was a regression introduced in:
73b777d

I believe the default configuration doesn't account for the version 1 builds of the jakarta.inject-api jar and the glassfish jakarta.inject jar contain the javax package name classes.

findbugs 3.0.0 plugin

java 8 javadoc lint

http://stackoverflow.com/questions/15886209/maven-is-not-working-in-java-8-when-javadoc-tags-are-incomplete

        <configuration>
            <additionalparam>-Xdoclint:none</additionalparam>
        </configuration>

under java 8 profile

PMD documented as updated, but wasn't

Commit 7f50d84 claims that the PMD version was upgraded to 5.8.1 (from 5.6.1), but the commit actually does not change the version.

maven scm 1.9.1

apache license file should support https: urls

needs a regexp to match both http and https. Maybe also report to the license plugin

Shade plugin fails with "Cannot load implementation hint 'org.basepom.maven.shade.CollectingManifestResourceTransformer'"

When using foundation, I get this error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:2.3:shade (default) on project foobar: Unable to parse configuration of mojo org.apache.maven.plugins:maven-shade-plugin:2.3:shade for parameter transformers: Cannot load implementation hint 'org.basepom.maven.shade.CollectingManifestResourceTransformer' -> [Help 1]

Looking at the configuration, it seems like there is a dependency missing in the shade plugin setup ?

Reason for useManifestOnlyJar=false

We're starting to run into issues with surefire due to the combination of very long classpaths plus basepom setting useManifestOnlyJar=false (surefire blows up with "Argument list too long"). I found the commit that originally set useManifestOnlyJar=false, but it didn't have much detail on the reasoning behind the change:
3cd0c9c#diff-cb497234fe84f30b3f9b347f2efe384bR352

The surefire documentation has a bit of detail on this argument, and seems to indicate that the default value of true is actually preferable:
https://github.com/apache/maven-surefire/blob/49887e043b9409dae1192915cf61c5cb755fd743/maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java#L223-L233

Do you happen to remember why it's set to false in basepom, and if there's anything we should look out for if we try setting it to true?

Suspected typo in maven-failsafe-plugin configuration

See https://github.com/basepom/basepom/blob/main/foundation/pom.xml#L407

I think it should be

<argLine>${basepom.coverage.it-args}…

($ instead of @). The way it is currently, tests cannot be run in my project using basepom version 45 with the error message Error: could not open {basepom.coverage.it-args}'`

Assuming I'm correct I could fork and provide a PR, but I don't know about contributors guidelines, so thought I'd ask first.

Bump to spotbugs 4.5.0

New spotbugs is out:
https://github.com/spotbugs/spotbugs/releases/tag/4.5.0

It looks like the maven plugin has included the code change in master but not yet cut a release:
https://github.com/spotbugs/spotbugs-maven-plugin

Maven shade 3.22+ has issues with the basepom CollectingManifestResourceTransformer

I get

Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:3.2.4:shade (assemble-app) on project demo-server: Unable to parse configuration of mojo org.apache.maven.plugins:maven-shade-plugin:3.2.4:shade for parameter transformers: Cannot load implementation hint 'org.basepom.maven.shade.CollectingManifestResourceTransformer': class org.basepom.maven.shade.CollectingManifestResourceTransformer overrides final method org.apache.maven.plugins.shade.resource.AbstractCompatibilityTransformer.processResource(Ljava/lang/String;Ljava/io/InputStream;Ljava/util/List;)V -> [Help 1]

add the moderizr

https://github.com/andrewgaul/modernizer-maven-plugin

pick up integration testing

there is no failsafe code in there.

git-commit-id-plugin fails on new projects with no tags

I'll try and make a PR for this if I can find a generic solution, at the moment I'm just turning off the plugin until after the first release.

Plugin For Consideration - maven-build-cache-extension

The maven-build-cache-extension has a lot of utility and it seems be be well thought out, but requires a very recent version of Maven (3.9.x). I'd like to see this added to basepom at some point when the maven version requirements are not quite so bleeding edge. Here are the versions for maven for two linux distros for some context:

Ubuntu Lunar (next version) seems to be staging version 3.8.3:

https://packages.ubuntu.com/lunar/java/maven

Fedora 38 (next version) seems to only be staging version 3.8.6:

https://packages.fedoraproject.org/pkgs/maven/maven/

Plugin Links:

surefire java util logging change

see airbase

Jakarta Activation Duplicate Classes

I am preparing to move some projects from the javax api namespace to the jakarta namespace and I'm finding some duplicate classes errors:

[WARNING] Found duplicate (but equal) classes in [com.sun.activation:jakarta.activation:2.0.1, jakarta.activation:jakarta.activation-api:2.0.1]:
[WARNING]   jakarta.activation.ActivationDataFlavor
[WARNING]   jakarta.activation.CommandInfo
[WARNING]   jakarta.activation.CommandMap
[WARNING]   jakarta.activation.CommandObject
[WARNING]   jakarta.activation.DataContentHandler
[WARNING]   jakarta.activation.DataContentHandlerFactory
[WARNING]   jakarta.activation.DataHandler
[WARNING]   jakarta.activation.DataHandlerDataSource
[WARNING]   jakarta.activation.DataSource
[WARNING]   jakarta.activation.DataSourceDataContentHandler
[WARNING]   jakarta.activation.FileDataSource
[WARNING]   jakarta.activation.FileTypeMap
[WARNING]   jakarta.activation.MailcapCommandMap
[WARNING]   jakarta.activation.MimeType
[WARNING]   jakarta.activation.MimeTypeParameterList
[WARNING]   jakarta.activation.MimeTypeParseException
[WARNING]   jakarta.activation.MimetypesFileTypeMap
[WARNING]   jakarta.activation.ObjectDataContentHandler
[WARNING]   jakarta.activation.SecuritySupport
[WARNING]   jakarta.activation.URLDataSource
[WARNING]   jakarta.activation.UnsupportedDataTypeException
[WARNING] Found duplicate classes/resources in compile classpath.
[WARNING] Found duplicate (but equal) classes in [com.sun.activation:jakarta.activation:2.0.1, jakarta.activation:jakarta.activation-api:2.0.1]:
[WARNING]   jakarta.activation.ActivationDataFlavor
[WARNING]   jakarta.activation.CommandInfo
[WARNING]   jakarta.activation.CommandMap
[WARNING]   jakarta.activation.CommandObject
[WARNING]   jakarta.activation.DataContentHandler
[WARNING]   jakarta.activation.DataContentHandlerFactory
[WARNING]   jakarta.activation.DataHandler
[WARNING]   jakarta.activation.DataHandlerDataSource
[WARNING]   jakarta.activation.DataSource
[WARNING]   jakarta.activation.DataSourceDataContentHandler
[WARNING]   jakarta.activation.FileDataSource
[WARNING]   jakarta.activation.FileTypeMap
[WARNING]   jakarta.activation.MailcapCommandMap
[WARNING]   jakarta.activation.MimeType
[WARNING]   jakarta.activation.MimeTypeParameterList
[WARNING]   jakarta.activation.MimeTypeParseException
[WARNING]   jakarta.activation.MimetypesFileTypeMap
[WARNING]   jakarta.activation.ObjectDataContentHandler
[WARNING]   jakarta.activation.SecuritySupport
[WARNING]   jakarta.activation.URLDataSource
[WARNING]   jakarta.activation.UnsupportedDataTypeException
[WARNING] Found duplicate classes/resources in runtime classpath.
[WARNING] Found duplicate (but equal) classes in [com.sun.activation:jakarta.activation:2.0.1, jakarta.activation:jakarta.activation-api:2.0.1]:
[WARNING]   jakarta.activation.ActivationDataFlavor
[WARNING]   jakarta.activation.CommandInfo
[WARNING]   jakarta.activation.CommandMap
[WARNING]   jakarta.activation.CommandObject
[WARNING]   jakarta.activation.DataContentHandler
[WARNING]   jakarta.activation.DataContentHandlerFactory
[WARNING]   jakarta.activation.DataHandler
[WARNING]   jakarta.activation.DataHandlerDataSource
[WARNING]   jakarta.activation.DataSource
[WARNING]   jakarta.activation.DataSourceDataContentHandler
[WARNING]   jakarta.activation.FileDataSource
[WARNING]   jakarta.activation.FileTypeMap
[WARNING]   jakarta.activation.MailcapCommandMap
[WARNING]   jakarta.activation.MimeType
[WARNING]   jakarta.activation.MimeTypeParameterList
[WARNING]   jakarta.activation.MimeTypeParseException
[WARNING]   jakarta.activation.MimetypesFileTypeMap
[WARNING]   jakarta.activation.ObjectDataContentHandler
[WARNING]   jakarta.activation.SecuritySupport
[WARNING]   jakarta.activation.URLDataSource
[WARNING]   jakarta.activation.UnsupportedDataTypeException
[WARNING] Found duplicate classes/resources in test classpath.

This is being triggered in part by Jackson's use of jakarta:

$ mvn dependency:tree
...
...
...
[INFO] |  |  +- com.fasterxml.jackson.jakarta.rs:jackson-jakarta-rs-json-provider:jar:2.14.2:compile
[INFO] |  |  |  +- com.fasterxml.jackson.jakarta.rs:jackson-jakarta-rs-base:jar:2.14.2:compile
[INFO] |  |  |  \- com.fasterxml.jackson.module:jackson-module-jakarta-xmlbind-annotations:jar:2.14.2:compile
[INFO] |  |  |     +- jakarta.xml.bind:jakarta.xml.bind-api:jar:3.0.1:compile
[INFO] |  |  |     |  \- com.sun.activation:jakarta.activation:jar:2.0.1:compile
[INFO] |  |  |     \- jakarta.activation:jakarta.activation-api:jar:2.0.1:compile
[INFO] |  |  +- jakarta.annotation:jakarta.annotation-api:jar:2.0.0:compile

I'm wondering if this should be a default exception in minimal.

basepom.check.skip-dependency skips all dependency goals, not just checks

We use dependency:copy to embed some files in our jar:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-dependency-plugin</artifactId>
  <executions>
    <execution>
      <id>setup-resources</id>
      <phase>generate-resources</phase>
      <goals>
        <goal>copy</goal>
      </goals>

When running a release with -Dbasepom.check.skip-all=true, our jar is incorrectly assembled, missing the expected resources.

It turns out that basepom configures all dependency goals with skip, not just checks:
https://github.com/basepom/basepom/blob/main/poms/foundation/pom.xml#L373

This was quite a surprise and led to our build being busted for hard-to-diagnose reasons.

Shade plugin documented as updated, but wasn't.

Commit ed80e16 claims the shade plugin was updated to 3.0.0, but the commit doesn't actually change that version.

change default git-id verbosity

very chatty with projects with many tags. @karlgoldstein.