- 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
http://mvnrepository.com/artifact/org.camunda.bpm.extension
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:
org.camunda.bpm.extension.#camunda-bpm-
For complex (multi module maven with examples):
org.camunda.bpm.extension.#camunda-bpm--root
-
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: https://camunda.org/contribute/ 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 …
cu
Jan