[VOTE] groupId for API artifacts

[Werner Keil]

Hi,

To get this more visible, here is an actual voting thread for the "API" components defined by subprojects.

With subproject being something like "config", "health",...

a) org.eclipse.microprofile with different artifactIds like microprofile-config-api for each subproject and kind of artifact

b) org.eclipse.microprofile.api for all "API" artifacts

c) org.eclipse.microprofile.<subproject> 

Please vote with +1/-1 or 0 for a, b or c.

There are at least two other threads related to artifact naming. If you want to comment on your preference, please be brief here or just link to another discusison, otherwise it could be harder to count everything.

The next overall Microprofile Hangout (#4) seems a good occasion to finalize and document a decision. 

Regards,

Werner

[Ondrej Mihályi]

I suppose that you meant this (adding more detail):

a) org.eclipse.microprofile maven group with different artifactIds like microprofile-config-api for each subproject (component) and kind of artifact

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

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

P.S. Wayne Beaton suggested using the term component instead sub-project of to avoid confusion within the Eclipse terminology

Ondrej

Dňa pondelok, 13. marca 2017 2:29:08 UTC+1 Werner Keil napísal(-a):

[Werner Keil]

Thanks for refining it.

There are projects with genuine subprojects listed under the project details, but I guess we shall see if it makes sense for MicroProfile over time.

[Emily Jiang]

Let's agree on the convention for this.

We had a config hangout and discussed the groupid and artificateid for config. We settle on the following convention:

<groupId>org.eclipse.microprofile.api</groupId>

<artifactId>microprofile-config-api</artifactId>

<version>1.0-SNAPSHOT</version>

<groupId>org.eclipse.microprofile.tck</groupId>

<artifactId>microprofile-config-tck</artifactId>

<version>1.0-SNAPSHOT</version>
Please shout now if you object. Otherwise, all other specifications/features should following this convention.

Emily

[John D. Ament]

I would rather see

groupId: org.eclipse.microprofile.<component>

artifactId: microprofile-<component>-api , microprofile-<component>-tck

Basically including the functional component in the groupId instead of the technical area.

John

[Ken Finnigan]

+1 to Johns suggestion

Sent from my iPhone

--
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/77b57dbf-a4e4-47b8-b9bb-ac216e14f752%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Werner Keil]

+1 on John's suggestion, too.

There could be a top level "Umbrella TCK" if various features should be tested against an application or framework claiming to be compatible, but that might be not much more than a POM or set of POMs poiting to the individual TCKs. Like what was done by JSR 363 https://github.com/unitsofmeasurement/unit-tck-usage or 354 https://github.com/JavaMoney/javamoney-tck-usage-example Of course this could also be more of a TCK guideline without actual code written in Asciidoc or Eclipse Wiki.

Werner

[Ondrej Mihályi]

The reason why we proposed to bundle api and tck artifacts under the same group is to make it easy to find all artifacts for users, and also separate them from other artifacts created by MicroProfile (e.g. sample applications, BOM, etc.)

Werner, Ken, John, would you at least accept if we grouped specification components under the same prefix, so that it's easy to separate specifications and other components like BOM, sample apps, etc? Like this:

org.eclipse.microprofile.spec.<component> - for spec components like config, healthcheck, e.g org.eclipse.microprofile.spec.config

org.eclipse.microprofile.<component> - for other non-spec components, e.g. org.eclipse.microprofile.conference-demo for the conference demo app

--Ondrej

Dňa piatok, 7. apríla 2017 15:01:01 UTC+2 Werner Keil napísal(-a):

[Mark Struberg]

+1 to Ondrejs proposal.

Will not make much difference now, but if we are successful, then this will ease adoption.

LieGrue,

strub

[John D. Ament]

Personally, I think we should start a separate discussion, rather than jump into a vote, to work through the pro's and con's of each packaging strategy.  We should also look to see if Eclipse has any requirements for group id/artifact id.  For example, many eclipse projects I've seen (not all) use the format of groupId = project's hierarchy, artifactId = groupId + some unique value for this artifact (for instance, groupId = org.eclipse.microprofile, artifactId = org.eclipse.microrprofile.config.api).  Considering how weird it is, and how it lines up with the header and notice just received from the Eclipse Foundation, I wouldn't be surprised if they're purposely related.

John

[Wayne Beaton]

The guidance is in the wiki (it will be moved to the handbook).

https://wiki.eclipse.org/Development_Resources/HOWTO/The_Eclipse_Code_Namespace_Policy#Maven_Group_Ids

Per Maven naming conventions, the Maven group id must follow the standard reverse DNS naming convention:

org.<forge>.<short-name>

Where:

• forge is the short name of the hosting forge, e.g. "eclipse", "locationtech", or "polarsys";
• "short-name" is the short name of the project (the name used in IPZilla, and the in project information pages]

We only talk about groupids. Within the group, you can name artifacts in whatever manner makes the most sense.

So... the groupid should be "org.eclipse.microprofile".

I'm curious to learn how this is weird.

Wayne

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b96dcfc0-eb24-4282-a291-94ecde70e513%40googlegroups.com.

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

--
Wayne Beaton
@waynebeaton
The Eclipse Foundation

[Alasdair Nottingham]

I think it is weird only if the rule requires it to be only org.eclipse.microprofile and doesn’t allow a org.eclipse.microprofile.<subtree>.

Alasdair

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f82aa01d-b821-dafe-f3b3-1d366c7cd3a9%40eclipse.org.

[John D. Ament]

On Monday, April 10, 2017 at 10:36:11 AM UTC-4, Wayne Beaton wrote:

The guidance is in the wiki (it will be moved to the handbook).

https://wiki.eclipse.org/Development_Resources/HOWTO/The_Eclipse_Code_Namespace_Policy#Maven_Group_Ids

Per Maven naming conventions, the Maven group id must follow the standard reverse DNS naming convention:

org.<forge>.<short-name>

Where:

• forge is the short name of the hosting forge, e.g. "eclipse", "locationtech", or "polarsys";
• "short-name" is the short name of the project (the name used in IPZilla, and the in project information pages]

We only talk about groupids. Within the group, you can name artifacts in whatever manner makes the most sense.

So... the groupid should be "org.eclipse.microprofile".

I'm curious to learn how this is weird.

The weird part I was referring to was the usage of groupId in the artifactId.  See here for an example.

 

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/b96dcfc0-eb24-4282-a291-94ecde70e513%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ondrej Mihályi]

I asked on the Eclipse incubation ML to clarify if we can use subgroups in groupIds, or only org.eclipse.microprofile would be allowed.

It is also weird to me that a project is required to use a single groupId. I can imagine that the Eclipse policy makes people think that no subgroups are allowed in the groupId, so they came up with subgroups in the artifact name. But the linked Maven conventions just say that the prefix should be consistent and allow subgroups at the end of groupIds, therefore I believe that we are allowed to use groupIds like org.eclipse.microprofile.<subgroup>.

But let's wait for Eclipse to clarify.

--Ondrej

Dňa utorok, 11. apríla 2017 5:28:11 UTC+2 John D. Ament napísal(-a):

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b96dcfc0-eb24-4282-a291-94ecde70e513%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ondrej Mihályi]

Here is my question on the Eclipse incubation ML:

https://dev.eclipse.org/mhonarc/lists/incubation/msg00311.html

--Ondrej

Dňa streda, 12. apríla 2017 0:41:42 UTC+2 Ondrej Mihályi napísal(-a):

[Ondrej Mihályi]

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

Dňa streda, 12. apríla 2017 0:42:59 UTC+2 Ondrej Mihályi napísal(-a):

[Ondrej Mihályi]

I created an updated poll in a new thread: https://groups.google.com/d/msg/microprofile/iWAimG6CtAM/rLax8myuAAAJ

--Ondrej

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