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

The client bom with dependencies should include kubernetes-model #924

Closed
iocanel opened this issue Nov 30, 2017 · 3 comments
Closed

The client bom with dependencies should include kubernetes-model #924

iocanel opened this issue Nov 30, 2017 · 3 comments
Assignees

Comments

@iocanel
Copy link
Member

iocanel commented Nov 30, 2017

No description provided.

@devang-gaur
Copy link
Contributor

Hey @iocanel , help me out here please! ( New to Maven ecosystem. )
After reading about BOM, I understand that main purpose of a BOM is to outsource the versioning conflicts of children modules, i.e., If I just specify a dependency DepA's version in my BOM under parent POM. Then I don't really require mentioning the DepA's version when its a direct dependency of the children/module's POM. Just a groupid and artifact id should suffice.

However, in the repo's case, the BOM specification in the parent POM doesn't mention a version and just sets a * regex ( https://github.com/fabric8io/kubernetes-client/blob/master/pom.xml#L239 ) and then, modules kubernetes-client and openshift-client pom have to specify the direct dependency versions in their pom ( https://github.com/fabric8io/kubernetes-client/blob/master/kubernetes-client/pom.xml#L165 ).

Doesn't this defeats the purpose of using a BOM?

I'm confused here. Please correct me if I'm wrong.

@rohanKanojia @rhuss @lordofthejars

devang-gaur pushed a commit to devang-gaur/kubernetes-client that referenced this issue Jul 30, 2018
devang-gaur pushed a commit to devang-gaur/kubernetes-client that referenced this issue Jul 30, 2018
@rohanKanojia
Copy link
Member

@dev-gaur : I think this bom is not something used by our project. We're providing this bom to be used by projects who have our project as a dependency in their pom, so that they don't have to worry about dependency version management.

@lordofthejars
Copy link
Contributor

@rohanKanojia You are right, the idea of bom is that you define deps of your own project to be consumed by other projects (not yourself although it is possible as well). The idea of bom is to simplify how others are going to use your library. Let's take a simple example with Spring Boot.

Spring Boot has several modules and not all of them are required at once, for example you could have spring-boot-core, spring-boot-data-sql, spring-boot-data-mongodb I don't know whatever it is just an example.

What you know is that core 1.1.0 works with data-sql 1.1.0 and data-monogb 1.1.0 but just with these versions and not any other ones, so you cannot mix core 1.2.0 with data-sql 1.1.0

So to have some way to lightly force this, Spring-Boot provides a bom. So you only need to register the bom in your project, and then in any dependency that you added that is specified in that bom, you don't need to set any version since it is taken from bom.

rohanKanojia pushed a commit to rohanKanojia/kubernetes-client that referenced this issue Aug 28, 2018
rohanKanojia pushed a commit to rohanKanojia/kubernetes-client that referenced this issue Aug 28, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants