[VOTE] Maven artifact groupIds (repeated)

[Ondrej Mihályi]

Since we've received clarification from Eclipse and the previous poll diverted into a discussion, I'll refresh the options we have in a new poll.

Option A) 

  groupId: org.eclipse.microprofile.api for all "API" artifacts, org.eclipse.microprofile.<subproject>.<module> for all other modules related to a subproject (component)

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.api : microprofile-config-api  - for the Config API artifact

    org.eclipse.microprofile.config.tck : microprofile-config-tck - for the Config TCK (non-API artifact in the config spec)

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app (a component not related to any spec)

    org.eclipse.microprofile.conference.session : microprofile-conference-session - for the session module of the Conference app (a module of a component not related to any spec)

Option B) 

  groupId: org.eclipse.microprofile.<subproject>.<module> for all modules related to a subproject (component)

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.config.api : microprofile-config-api  - for the Config API (only this one is different from option b)

    org.eclipse.microprofile.config.tck : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app

    org.eclipse.microprofile.conference.session : microprofile-conference-session - for the session module of the Conference app

Option C) 

  groupId: org.eclipse.microprofile.spec.<subproject> for all spec subprojects, org.eclipse.microprofile.<subproject> for all other subprojects not related to any spec

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.spec.config.api : microprofile-config-api  - for the Config API

    org.eclipse.microprofile.spec.config.tck : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app

    org.eclipse.microprofile.conference.session : microprofile-conference-session - for the session module of the Conference app

I removed the option A) in the original thread because not relevant anymore. I added a new option C.

Summary of the options:

 - the last 2 examples for conference project are always the same for all options

 - options A and B differ only in the first example

 - the option C is similar to the option B, but adds a common "spec" namespace for all specification subprojects, so that they don't mix with other subprojects like demo apps, etc.

Please vote again.

--Ondrej

Dňa štvrtok, 13. apríla 2017 19:20:58 UTC+2 Ondrej Mihályi napísal(-a):

Hi,

We have a strong confirmation that we can use subgroups in our maven artifacts - it's enough if the groupId begins with the prefix "org.eclipse.microprofile.", see here: https://dev.eclipse.org/mhonarc/lists/incubation/msg00315.html

So having org.eclipse.microprofile.config and similar, even org.eclipse.microprofile.config.api, is all OK.

Thanks to the Eclipse Fnd. representatives to have responded so fast!

--Ondrej

[Mark Struberg]

+1 for Option A.

LieGrue,

strub

[John D. Ament]

Option C for me.

[Ondrej Mihályi]

Option A

Dňa štvrtok, 13. apríla 2017 19:47:51 UTC+2 Ondrej Mihályi napísal(-a):

[Emily Jiang]

I would like to add Option D)

Option D) 

  groupId: org.eclipse.microprofile.spec for all spec subprojects,

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.spec.config : microprofile-config-api  - for the Config API

    org.eclipse.microprofile.spec.config : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app

    org.eclipse.microprofile.conference : microprofile-conference-session - for the session module of the Conference app

The same project will have the same the groupid.

[Ken Finnigan]

My preference would be for a combination of C and D. Dropping the spec part from the groupId, and a separate groupId for root level things like BOM.

Examples:

org.eclipse.microprofile : microprofile-bom

org.eclipse.microprofile.config : microprofile-config-api

org.eclipse.microprofile.config : microprofile-config-tck

org.eclipse.microprofile.conference : microprofile-conference

org.eclipse.microprofile.conference : microprofile-conference-session

Ken

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b3a8cd9d-d384-4ab7-8f27-c898f4a30376%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Werner Keil]

+1 

I am also for B or a variation Ken suggested.

Having one or the other parent POM or BOM in a package/bundle like org.eclipse.microprofile seems OK, but the risk of an uber-bundle like "org.eclipse.microprofile.api" will get even worse when Java 9 comes into play. 

For JAR artifacts I would try to keep the groupId and Java package as close together as possible. And at least for the package, Jigsaw will not allow splitting a package across two different modules. So splitting groupIds randomly across dozens of different packages with a totally different names will pretty likely cause a "Module Hell" especially if Auto-module assumptions come into play for existing JARs built with Java 8.

Werner

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Ondrej Mihályi]

Werner, I understand your point, but there's no valid reason why maven group should be the same as java packages.

E.g. a paclage name doesn't even have to have "api" in the namespace (e.g. microprofile.config.Config lookd better than microprofile.config.api.Config)

Those 2 are simply not related.

My reason for voting for option A is simply usability - when searching for a maven artifact, it's easier if all API artifacts are in the same group. But I also understand that may not be relevant if the majority of users would just use the BOM as an aggregator, similarly to javaee-api artifact.

--Ondrej

[Emily Jiang]

I consolidated the options again, taking B and D from Ondrej and add Ken's suggestions on top of mine to be Option D

Option B) 

  groupId: org.eclipse.microprofile.<subproject>.<module> for all modules related to a subproject (component)

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.config.api : microprofile-config-api  - for the Config API (only this one is different from option b)

    org.eclipse.microprofile.config.tck : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app

    org.eclipse.microprofile.conference.session : microprofile-conference-session - for the session module of the Conference app

Option C) 

  groupId: org.eclipse.microprofile.spec.<subproject> for all spec subprojects, org.eclipse.microprofile.<subproject> for all other subprojects not related to any spec

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.spec.config.api : microprofile-config-api  - for the Config API

    org.eclipse.microprofile.spec.config.tck : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app

    org.eclipse.microprofile.conference.session : microprofile-conference-session - for the session module of the Conference app

Option D) 

  groupId: org.eclipse.microprofile.spec for all spec subprojects,

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.config : microprofile-config-api  - for the Config API

    org.eclipse.microprofile.config : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app

    org.eclipse.microprofile.

conference : microprofile-conference-session - for the session module of the Conference app

Let's vote again. So far, Ken, Wrener voted D. I will add my +1 on D.

Let's aim to finalise this by the end of this week. The vote will close by EOD Friday (GMT +1) this week. I will announce the most voted option by then.

Thanks
Emily

[Werner Keil]

Emily,

Thanks for summarizing those.

Could you give an example for org.eclipse.microprofile.spec?

My understanding (and likely those by all the others who voted for it) was that "spec" is primarily the written documentation, Asciidoc or similar, not API or any other executable code.

Those in D are supposed to be under org.eclipse.microprofile.<subproject> e.g. org.eclipse.microprofile.config.

As module lead for Config, even though it is just a snapshot (so naturally subject to change) can you explain how an "Option E" made its way into

https://repo.eclipse.org/content/repositories/microprofile/org/eclipse/microprofile/ ?

With

 org.eclipse.microprofile.apis : microprofile-config-api  - for the Config API

 org.eclipse.microprofile.config : microprofile.config.parent - for the Config Parent POM

 org.eclipse.microprofile.config.tck : microprofile-config-tck - for the Config TCK

This not only mixed some unvoted and unconsolidated "apis" groupId into all the options discussed,

it also mixes an artifactId in a more traditional (OSGi inspired) Eclipse style of "microprofile.config.parent" with a dash-style "microprofile-config-tck".

It looks very chaotic and now that at least Snapshots are published, those are there to stay (nobody except maybe Eclipse Webmasters will ever be able to remove them)

Cheers,

Werner

[Ken Finnigan]

On Wed, Apr 26, 2017 at 5:25 AM, 'Emily Jiang' via MicroProfile <microp...@googlegroups.com> wrote:

I consolidated the options again, taking B and D from Ondrej and add Ken's suggestions on top of mine to be Option D

Option B) 

  groupId: org.eclipse.microprofile.<subproject>.<module> for all modules related to a subproject (component)

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.config.api : microprofile-config-api  - for the Config API (only this one is different from option b)

    org.eclipse.microprofile.config.tck : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app

    org.eclipse.microprofile.conference.session : microprofile-conference-session - for the session module of the Conference app

Option C) 

  groupId: org.eclipse.microprofile.spec.<subproject> for all spec subprojects, org.eclipse.microprofile.<subproject> for all other subprojects not related to any spec

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.spec.config.api : microprofile-config-api  - for the Config API

    org.eclipse.microprofile.spec.config.tck : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app

    org.eclipse.microprofile.conference.session : microprofile-conference-session - for the session module of the Conference app

Option D) 

  groupId: org.eclipse.microprofile.spec for all spec subprojects,

I don't agree with this part of Option D, I don't see the need for ".spec" in the groupId.

If we drop ".spec" then I'm +1 on D

Ken

 

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.config : microprofile-config-api  - for the Config API

    org.eclipse.microprofile.config : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app

    org.eclipse.microprofile.

conference : microprofile-conference-session - for the session module of the Conference app

Let's vote again. So far, Ken, Wrener voted D. I will add my +1 on D.

Let's aim to finalise this by the end of this week. The vote will close by EOD Friday (GMT +1) this week. I will announce the most voted option by then.

Thanks
Emily

On Monday, April 17, 2017 at 10:42:06 PM UTC+1, Ondrej Mihályi wrote:

Werner, I understand your point, but there's no valid reason why maven group should be the same as java packages.

E.g. a paclage name doesn't even have to have "api" in the namespace (e.g. microprofile.config.Config lookd better than microprofile.config.api.Config)

Those 2 are simply not related.

My reason for voting for option A is simply usability - when searching for a maven artifact, it's easier if all API artifacts are in the same group. But I also understand that may not be relevant if the majority of users would just use the BOM as an aggregator, similarly to javaee-api artifact.

--Ondrej

--

You received this message because you are subscribed to the Google Groups "MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d449477d-3306-4f06-8217-279b160f140b%40googlegroups.com.

[Werner Keil]

Again I would understand the ".spec" part entirely for deployment of Asciidoc artifacts.

I have no problem dropping the ".spec" part and treating the Asciidoc artifacts like everything else e.g. 

"org.eclipse.microprofile.config" (it could happily live next to the parent POM under that groupId)

Werner

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Emily Jiang]

Ken, I overlooked the template .spec. I updated it to be submodule.

Here is the updated version.

Option B) 

  groupId: org.eclipse.microprofile.<subproject>.<module> for all modules related to a subproject (component)

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.config.api : microprofile-config-api  - for the Config API (only this one is different from option b)

    org.eclipse.microprofile.config.tck : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app

    org.eclipse.microprofile.conference.session : microprofile-conference-session - for the session module of the Conference app

Option C) 

  groupId: org.eclipse.microprofile.spec.<subproject> for all spec subprojects, org.eclipse.microprofile.<subproject> for all other subprojects not related to any spec

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.spec.config.api : microprofile-config-api  - for the Config API

    org.eclipse.microprofile.spec.config.tck : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app

    org.eclipse.microprofile.conference.session : microprofile-conference-session - for the session module of the Conference app

Option D) 

  groupId: org.eclipse.microprofile.<subproject>

  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.config : microprofile-config-api  - for the Config API

    org.eclipse.microprofile.config : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app

    org.eclipse.microprofile.

conference : microprofile-conference-session - for the session module of the Conference app

Werner, 

The repo publish happened last week while I was off. Hope we will be able to consolidate the vote and apply the change accordingly! If necessary, we will need to remove the old image from the repo.

Thanks

Emily

[Ken Finnigan]

Thanks for clarification Emily.

I'm +1 on D

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/94ea9879-c76a-4c23-acce-e15ce36eedf2%40googlegroups.com.

[Alasdair Nottingham]

I think I’m +1 on D. 

I’ve found this thread a little difficult to follow, but I prefer the group scheme of d, but I don’t really care for the artifactId scheme, but I don’t have a better suggestion and to be honest my dislike kind of relates to a general dislike of how group and artifact id works in maven anyway so a moot point for this thread.

Alasdair

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAKeeVe4aj9m-pnHykE22GWxHs4075RAx-45POGyP1qVNPCavxg%40mail.gmail.com.

[Werner Keil]

Although it should have been recorded already, +1 for D.

A little mishap in the Snapshot repo hopefully won't repeat itself once the naming pattern was decided on and all subprojects/features stick to it.

Werner

[Heiko Braun]

I voting for a combination of B & D.

B makes sense for subprojects with modules that have multiple artifacts. Without they could simply use D.

[Emily Jiang]

Heiko,
We don't have any modules with multiple artifacts. For an instance, config api will have just one artifact not multiple. In this case, are you voting for Option D then. Just try to clarify.
Emily

[Mark Struberg]

No emily, config has 3 published artifacts:
Api, tck, spec-pdf

Check the repo

[Werner Keil]

And a parent POM.

[Emily Jiang]

Mark,
I am aware of the three jars for config. I am trying to clarify the module and spec:

For Config,

spec: config
module: api, tck, spec-pdf

each module only has one jar, which means one artifact per module.

I think you mixed spec and module. Maybe we should agree on the terms first.

Emily

[Werner Keil]

The naming and structure of those artifacts that already went to a Maven Snapshot repo very much suggest API and Spec being mistaken by some.

The Parent POM does not include a JAR but it's also an artifact of its own.

Werner

[Emily Jiang]

My vote: +1 on D!
Vote will be closed on Tuesday.
Emily

[Emily Jiang]

Summarise the vote:
Option A: 2 votes (Mark, Ondrej)
Option B: 1 vote (John Ament)
Option D: 4 votes (Ken, Werner, Alasdair, Emily)
Option B+D: 1 vote (Heiko)

The winner is option D. I will raise an issue to get the config repo fixed. Please shout if you spot any discrepancies.

Thanks
Emily

[John D. Ament]

For the record, I voted for the original "C" not "B" and if option D were on the original proposal I would have voted for that instead.  We need to avoid changing the vote options while the vote is going on, and focus on better up front communication to make sure all options are known.

[Emily Jiang]

There was disagreement on the suggestions. When trying to vote, I suggested something else. Maybe it is better to stop the original thread and start a new one for the voting. We are just trying to find a better process to handle this. Sorry to get your vote wrong. However, this does not change the winner:o.

Back to this topic, I think the final conclusion is D. I have done a PR in the config repo to reflect this decision.

Thanks
Emily

[Ondrej Mihályi]

I think that option D is a clear winner.

I wouldn't repeat the vote, but next time we should separate the discussion from voting.

--Ondrej

[Alasdair Nottingham]

+1 (this is where I really want to do +2 to show a more enthusiastic agreement, but I’m sure someone would claim I were trying to vote twice.)

Alasdair

> --
> You received this message because you are subscribed to the Google Groups "MicroProfile" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
> To post to this group, send email to microp...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/16669251-3ea8-4432-b765-0c2e7833e65c%40googlegroups.com.

[Ondrej Mihályi]

I've documented the naming convention we'd agreed on (option D) in the wiki: https://wiki.eclipse.org/MicroProfile/ContributingGuidelines#Deliverable_group_and_artifact_naming_convention

--Ondrej

[Ondro Mihályi]

I'll reuse this thread to continue the discussion about artifact group naming.

After I documented the option D which seemed to be the most popular option (on the wiki here), today I realized that MP Config artifacts didn't completely follow the naming schema.

According to the option D and according to the wiki, the artifact group for MP Config should be org.eclipse.microprofile.spec.config, but the word "spec" is omitted and the released artifacts have group org.eclipse.microprofile.spec.config

I checked repositories of other features in the works and they also use the group name without "spec", such as org.eclipse.microprofile.health or org.eclipse.microprofile.metrics

Since nobody adopted the most agreed option but all seem to stick to the same schema, I suggest to change the guidelines to drop the word spec. We would lose the ability to have a separate namespace for features from other MicroProfile artifacts, but since the other artifacts will probably never be published in Maven central, it doesn't matter so much.

--Ondro

[Emily Jiang]

+1! Thanks for bringing this up! org.eclipse.microprofile.config is shorter than org.eclipse.microprofile.spec.config.
It also matches to the repo name.

Emily