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

JCL-321: Use com.inrupt.client for Maven groupId #401

Merged
merged 4 commits into from
Apr 6, 2023
Merged

Conversation

acoburn
Copy link
Collaborator

@acoburn acoburn commented Apr 4, 2023

This changes the groupId of the client libraries from com.inrupt to com.inrupt.client

@acoburn acoburn requested a review from hzbarcea April 4, 2023 19:48
@acoburn acoburn requested a review from a team as a code owner April 4, 2023 19:48
@acoburn acoburn temporarily deployed to ESS PodSpaces April 4, 2023 19:49 — with GitHub Actions Inactive
@acoburn acoburn temporarily deployed to ESS PodSpaces April 4, 2023 19:49 — with GitHub Actions Inactive
@acoburn acoburn temporarily deployed to ESS DevNext April 4, 2023 19:49 — with GitHub Actions Inactive
@acoburn acoburn temporarily deployed to ESS PodSpaces April 4, 2023 20:11 — with GitHub Actions Inactive
@acoburn acoburn temporarily deployed to ESS PodSpaces April 4, 2023 20:11 — with GitHub Actions Inactive
@acoburn acoburn temporarily deployed to ESS DevNext April 4, 2023 20:11 — with GitHub Actions Inactive
@hzbarcea
Copy link

hzbarcea commented Apr 4, 2023

Looks good. Another (arguably better) option would be to leave groupId=com.inrupt in the root project and create a ./parent subproject (with groupId=com.inrupt.client) and move all dependency management there. Then all modules would have this as the project with a <relativePath>../parent</relativePath>.

A bit cleaner, a bit more work. This works too, for all practical purposes almost the same thing.

@hzbarcea
Copy link

hzbarcea commented Apr 4, 2023

Documentation will need some updates.

@acoburn
Copy link
Collaborator Author

acoburn commented Apr 4, 2023

I had also been considering the creation of an independent "parent" project, living in its own repo. Then that parent can be consumed by all Java projects in Inrupt, including these client library. That change would basically involve moving most of the current root pom.xml into a separate repo and then just consuming that from here.

@acoburn
Copy link
Collaborator Author

acoburn commented Apr 5, 2023

@hzbarcea the pattern you describe is something I see quite a bit elsewhere. What do you see as the advantage of having a special ./parent module over having everything in a single root pom.xml? The main advantage I see is that it means the project can put all the dependency management and plugin configuration in a single place, without mixing that with other project metadata (scm, modules, developers, etc). And do you see that as preferable over having, for example, a multi-project parent POM, a-la Apache's parent POM that is used by most projects in the ASF?

@acoburn acoburn temporarily deployed to ESS PodSpaces April 5, 2023 17:58 — with GitHub Actions Inactive
@acoburn acoburn temporarily deployed to ESS PodSpaces April 5, 2023 17:58 — with GitHub Actions Inactive
@acoburn acoburn temporarily deployed to ESS DevNext April 5, 2023 17:58 — with GitHub Actions Inactive
@hzbarcea
Copy link

hzbarcea commented Apr 5, 2023

@hzbarcea the pattern you describe is something I see quite a bit elsewhere. What do you see as the advantage of having a special ./parent module over having everything in a single root pom.xml? The main advantage I see is that it means the project can put all the dependency management and plugin configuration in a single place, without mixing that with other project metadata (scm, modules, developers, etc). And do you see that as preferable over having, for example, a multi-project parent POM, a-la Apache's parent POM that is used by most projects in the ASF?

You are correct. My personal preference is to have that separation, but I recognize that it's quite subjective.

@hzbarcea
Copy link

hzbarcea commented Apr 5, 2023

Pressed too fast. The second topic you mentioned (separate and orthogonal): having a parent project for all java projects, is imho more interesting and maybe more important. That would ensure a consistent dependency management across all (or most) java projects. It would make many things easier (faster, cheaper, better) in terms of versions baseline management, upgrades, testing, deviations from baseline. It could be done at any time though, but the earlier the better.

@acoburn acoburn temporarily deployed to ESS PodSpaces April 6, 2023 12:08 — with GitHub Actions Inactive
@acoburn acoburn temporarily deployed to ESS PodSpaces April 6, 2023 12:08 — with GitHub Actions Inactive
@acoburn acoburn temporarily deployed to ESS DevNext April 6, 2023 12:08 — with GitHub Actions Inactive
@acoburn acoburn enabled auto-merge (squash) April 6, 2023 12:08
@acoburn acoburn merged commit c08c58a into main Apr 6, 2023
@acoburn acoburn deleted the JCL-321-groupid branch April 6, 2023 12:27
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.

3 participants