Maven coordinate (re)discussion

[Kevin Sutter]

Hi,
I know we discussed this on the mailing list [1] and it's documented on our wiki [2], but I've run across a couple of scenarios in real-life usage that we need to clarify...

As a reminder, here's what we agreed to (without having to re-read all of the links below):

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

This works good for the submodule poms, but what about the top-level poms for the subproject?

For example, Config has the following:

    <groupId>org.eclipse.microprofile.config.parent</groupId>
    <artifactId>microprofile-config-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>
    <name>MicroProfile Config</name>

But, putting the ".parent" and "-parent" suffixes, it breaks the directory hierarchy in the maven repository.  Now the submodule artifacts are not in the same directory structure as the subproject.

As part of my work for defining the top-level MicroProfile 1.1 pom, I went this way instead:

    <groupId>org.eclipse.microprofile</groupId>
    <artifactId>microprofile-bom</artifactId>
    <packaging>pom</packaging>
    <version>1.1.0-SNAPSHOT</version>

This "-bom" suffix on the artifactId idea was borrowed from the WildFly-related projects that we pull in for our build and test dependencies.  I kind of liked it.  It shows that this is clearly a convenience artifact that is used to pull in a bunch of other "real" artifacts.

So, to that end, I would like to propose that the top-level subproject poms are defined as follows:

groupId: org.eclipse.microprofile.<subproject>

artifactId: microprofile-<subproject>-bom

Thus, the Config top-level pom should change to this:

    <groupId>org.eclipse.microprofile.config</groupId>
    <artifactId>microprofile-config-bom</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>
    <name>MicroProfile Config</name>

Thoughts?  Or, other suggested improvements?  I just don't like that extra ".parent" and/or "-parent" since it screws up the directory hierarchy.  And, I want something consistent for our top-level bom pom.xml coordinates.

Thanks!
Kevin

[1]  https://groups.google.com/forum/#!msg/microprofile/iWAimG6CtAM/hJbFU8-rBAAJ
[2]  https://wiki.eclipse.org/MicroProfile/ContributingGuidelines#Deliverable_group_and_artifact_naming_convention

[John D. Ament]

Usually the -bom suffix on an artifact is for the list of distribution materials.  -parent is for the top level artifact.  So I would see microprofile-config-bom to have a dependencyManagement section only, with only the config artifacts in place.  Whereas typical parents include all of the dependencies used in the project and their versions.

My rule of thumb has always been:

-parent: for the developers of the project to use

-bom: for the users of the project to use

John

[Kevin Sutter]

Good clarification, John.  Thanks.

I can see the use of both -bom and -parent, depending on the circumstance and usage scenarios.  So, maybe the only "issue" is the use of the ".parent" in the groupId (since it messes up with the maven directory structure).  Would it work to have the top-level Config pom defined as follows?

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

    <artifactId>microprofile-config-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>
    <name>MicroProfile Config</name>

--  Kevin

[Emily Jiang]

+1 on changing the group id to org.eclipse.microprofile.config, which is nicer as well. I tried and it does work. I'll do a PR shortly if no one objects.

Emily

[John D. Ament]

Right, and if I were looking at the core repo I would expect to see a parent at the root and a bom in a subdirectory.  

[Kevin Sutter]

Can you expand on that a bit, John?  What do you mean by "core" repo?  In the context of our multiple Eclipse MP repos?

Thanks, Kevin

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/045kUmJyfgI/unsubscribe.
To unsubscribe from this group and all its topics, 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/f99d3e18-4c94-42a3-b168-4a556b572002%40googlegroups.com.

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