Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the BOM suitable to be a parent of other projects #5

Open
andrus opened this issue Nov 22, 2023 · 0 comments
Open

Make the BOM suitable to be a parent of other projects #5

andrus opened this issue Nov 22, 2023 · 0 comments

Comments

@andrus
Copy link
Contributor

andrus commented Nov 22, 2023

Not yet ready for prime time due to the issues describe below, related to the limitations of the Maven inheritance. Maybe we need a Bootique Maven plugin to address them?

While we got rid of bootique-parent that was available in 1.0 to simplify jar shading, we may need another flavor of parent POM for better dependency management. And our current BOM may just be that POM.

Problem 1 - Manual Management of 3-Party Module Versions

As an app developer, I would like to include a module from a dependency already integrated in Bootique, and I want to ensure it is the same version as the one in Bootique. E.g. agrest-annotations are often included in modules that otherwise do not depend on bootique-agrest. The current solution is to define the version as a property, and manually update it every time a Bootique update happens:

<properties>
        <agrest.version>5.0.M18</agrest.version>
</properties>

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>io.agrest</groupId>
                <artifactId>agrest-annotations</artifactId>
                <version>${agrest.version}</version>
            </dependency>
        </dependencies>
</dependencyManagement>

It would be great if we could "inherit" this version from Bootique somehow, and nor maintain it manually. Would be even better if all these dependencies already known to Bootique, would be inherited with proper versions.

Problem 2 - Overriding 3-Party Module Versions

Sometimes I want to override the version of a third-party lib managed by Bootique to a different one. E.g. there was a bugfix , and I can't wait till it makes it to Bootique. Currently it requires explicit declarations in the <dependencyManagement> section, similar to the example above, except we also need to infer and list every single module from that project.

Suggested Solution

In addition to "import", allow to set our BOM as a "parent" of user projects. This would allow to incorporate dependency declarations, but also easily override thrid-party versions with custom values via properties. There are a few things that we need to do to make it work:

  • Make the BOM bare-bone to minimize the things that are inherited and can pollute the app. Things like <description>, <licenses>, <url> should be stripped off
  • In <properties>, declare the versions of all the third-party libraries, using a common prefix for property names (bq prefix has special meaning in the Bootique apps, so maybe use something else?)
  • In <dependencyManagement>, in addition to Bootique module declarations, also declare the main frameworks integrated in Bootique (with excludes?)

Problems with this Solution

Inheriting from a 3rd-party POM has a bunch of negative consequences:

  • In addition to desired dependencies and property versions, the apps will also inherit various undesired POM parameters like scm, repositories, license, distributionManagement, etc.
  • A huge <dependencyManagement> section can result in unexpected interference with project-specific stuff. IIRC this created problems with various transitional Jakarta jars (JAXB, etc.), when the app had its own dependencies that won't work with certain Bootuque modules, even in the absence of those modules.
  • Using parent SNAPSHOT version would require a snapshot repository declaration in each project.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant