Skip to content

Conversation

@jafarre-bi
Copy link

@jafarre-bi jafarre-bi commented Jul 6, 2025

commons-vfs2-bom has commons-vfs2-project as a parent. When you import it into a different project, you expect to have this project's dependencies managed only, but instead, you get numerous other dependencies managed from commons-vfs2-project and its parents.
This pull request detaches the BOM from its parent, which is the only way to get rid of unwanted dependency management.
Unfortunately, as the BOM is part of the reactor, other parts of the parent POM are required for the build to succeed, and we must manually copy them. The only solution for this would be to remove the BOM from the reactor itself, as building a BOM is trivial and probably allows for a much simpler POM file to be written for it. However, the BOM would then need to be built separately.

Link to the Jira issue: VFS-860

@jafarre-bi jafarre-bi marked this pull request as draft July 6, 2025 20:42
@garydgregory
Copy link
Member

The link in the description is not to the Jira issue.

So far this doesn't seem to be what Maven recommends, or am I missing something?

@jafarre-bi
Copy link
Author

jafarre-bi commented Jul 6, 2025

The link in the description is not to the Jira issue.

Fixed

So far this doesn't seem to be what Maven recommends, or am I missing something?

This is from Maven documentation:

The root of the project is the BOM POM. It defines the versions of all the artifacts that will be created in the library. Other projects that wish to use the library should import this POM into the dependencyManagement section of their POM.

and

The parent subproject has the BOM POM as its parent. It is a normal multiproject pom.

This can't be done in Apache Commons projects because they need to inherit from org.apache.commons:commons-parent.
We also can't make the BOM inherit from commons-parent because it would also inherit unwanted dependency management, namely, junit and mockito. Avoiding this implies removing the dependency management section from commons-parent, which implies adding it to the parent of every single project under it.

The solutions I can think of are:

  1. Leave things the way they are. Then, the only way to fix the problem would be to remove the dependency management section from commons-vfs2-project. You would still be inheriting unwanted dependency management from commons-parent.
  2. Follow the Maven documentation recommendations. Then the BOM will inherit from commons-parent, and commons-vfs2-parent will inherit from the BOM. You would still be inheriting unwanted dependency management from commons-parent.
  3. Modify the BOM so that it does not have a parent, and keep it within the reactor. This way, you don't have the option to import the BOM into the parent's dependency management section.
  4. Modify the BOM so that it does not have a parent, remove it from the reactor, and import it into the parent. But then you need to build the BOM independently of (and before) the other modules.

This draft PR implements option 3, but any option is acceptable for me.

Option 1:
org.apache:apache
|
-- commons-parent -> Ideally, we would remove the dependency management.
|
---- commons-vfs2-project -> We need to remove the dependency management and move it somewhere else.
|
------ commons-vfs2-bom
------ (other vfs2 modules)

Option 2:
org.apache:apache
|
-- commons-parent -> Ideally, we would remove the dependency management.
|
---- commons-vfs2-bom -> Most similar to Maven recommendations.
|
------ commons-vfs2-project
|
-------- (other vfs2 modules)

Option 3:
org.apache:apache
|
-- commons-parent
|
---- commons-vfs2-project --- Included in the reactor ---> commons-vfs2-bom -> Can't be imported into the parent.
|
------ (other vfs2 modules)

Option 4:
org.apache:apache
|
-- commons-parent
|
---- commons-vfs2-project --- Imported --> commons-vfs2-bom -> Needs to be built independently.
|
------ (other vfs2 modules)

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

Successfully merging this pull request may close these issues.

2 participants