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

Pull-up plugin-management of maven-deploy-plugin to the BOM #402

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

k-wall
Copy link

@k-wall k-wall commented Mar 14, 2024

Pull-up plugin-management of maven-deploy-plugin to the BOM so that the version of the plugin used to deploy the BOM is the same as that used to deploy the remainder of the project.

why: currently the version of the deploy plugin used to deploy the BOM not controlled by the build. So it will be under the influence of the local Maven environment. This could effect build repeatability.

the version of the plugin used to deploy the BOM is the same as that used to
deploy the remainder of the project.

Signed-off-by: kwall <kwall@apache.org>
@k-wall k-wall changed the title Pull-up dependency-management of maven-deploy-plugin to the BOM Pull-up plugin-management of maven-deploy-plugin to the BOM Mar 14, 2024
@ceki
Copy link
Member

ceki commented Mar 15, 2024

I think moving to Maven 4 is the way to go for supporting BOM files.

@hazendaz
Copy link
Contributor

I don't thinks this request is anything to do with maven 4 or BOM related. The BOM here is just the top level of the build. The suggestion was to just move it up to top level. I think the word BOM should have been left out and just said to be moving it up to root of the project. However, this screams many other issues. The parent is on same level as the modules which is bad design with maven. And its that parent that wants to pull from the bom. Its a bit backwards. This all becomes clear the moment relativePath is being rewritten everywhere needlessly. I think the bom should be a module that runs last since it depends on all. While the build works, having a bom with dependency management that doesn't actually exist at that point is odd design. But if done at the end of the build it would make more sense logically as those modules really would exist by then.

As it stands do I think this change alone is worth the effort, not really. Do note I'm not a owner or frequent contributor or anything here. Just saying moving like this kind of avoids the real issues and is a whack a mole situation. Maybe this repo might give a pointer to help https://github.com/Waffle/waffle/tree/master/Source/JNA. Do note its down pretty far in source due to having dotnet stuff higher up (needs split). There is a pom further up used to launch everything but cannot be used to release and it suffers same issues. It wants to be on same plugins but the plugins are defined in the parent. But if you ignore that part and just look at that folder structure you will see it has the parent pom driving the thing and the bom is just a module not the parent-parent.

@rnc
Copy link

rnc commented Mar 18, 2024

While I agree with @hazendaz in that I don't believe its anything per se to do with a BOM I do however think this minor change would be good to apply. If anyone rebuilds SLF4J and uses altDeploymentRepository this will lead to inconsistent results as Maven changed the format of that between 2.x and 3.x - and as SLF4J uses both versions of the maven-deploy-plugin this can occur.

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.

None yet

4 participants