groupId for community extensions - clean repository structure

  • Not sure if this is related to “contribution” or “extension” … imho, the extension channel should be used to discuss usage and possible features of community extensions, not development details. So I put this here:

When we discussed the naming convention for community extensions, we came up with

group-id: org.camunda.bpm.extension
artifact-id: camunda-bpm-
A common pattern for name is also “-root” for multi maven modules and “-example-” for examples.

While this sounds reasonable for a single extension, now with a large (and growing) number of extensions, the concepts is beaten by its own success: checking

its hard to find out which extensions exists, because root/examples/core of many extension just lie in one flat structure. Exceptions are osgi and camel … those where happy enough not to care for the naming convention at all and thus created their own subfolders …

I would like to set a new naming pattern for extensions:

  • let be the extensions name, then we have:

For simple (plain maven) extension:


For complex (multi module maven with examples):


  • o.c.b.e.#camunda-bpm--extension-root
    – o.c.b.e.#camunda-bpm-(-core)
    – …

  • o.c.b.e..examples#camunda-bpm--examples-root
    – o.c.b.e..examples#camunda-bpm--example-simple
    – …

one could also think about putting all those “root” intermediate poms in a o.c.b.e..root groupId so the do not clutter the “pure” extensions when checking whats there.

I’d like to hear your opinion on this … as a result, we would have to change the naming rules here: and adopt the changes to the extension blueprint.

Interesting question how we would deal with the existing structure … do we just keep everything as-is for existing projects? do we change the groupi with the next release? Do we even abandon the bpm.extension branch and start fresh in bpm.communityextension …