I really don't think it's advisable to reuse the janusgraph-cassandra artifactId. It's extremely unexpected for the meaning of an artifactId to change after a version bump.
Essentially janusgraph-cassandra would cease to mean the jar containing the JanusGraph Cassandra backend implementation and would become the parent POM for the Cassandra modules. This would have strange effects on anyone depending on that artifactId after the version change.
In regards to using different groupIds for sub-modules, that's not a bad solution but given the relatively small number of modules overall might be a bit unnecessary.
I favour continuing to use the org.janusgraph groupId for all modules and dropping the janusgraph prefix both in the directories and in the artifactIds as it seems a bit redundant since all the modules are scoped under the org.janusgraph groupId.
Another possibility to consider is to introduce an intermediate level for backend and index implementations:
/
├── docs/
├── dist/
├── janusgraph/
│ ├── core/
│ └── test/
├── backend/
│ ├── berkeleyje/
│ ├── cassandra/
│ | ├── core/
│ | ├── test/
│ | ├── astyanax/
│ | └── cql/
│ └── hbase/
│ ├── core/
│ ├── test/
│ ├── hbase-098/
│ └── hbase-10/
├── index/
│ ├── elasticsearch/
│ ├── lucene/
│ └── solr/
└── hadoop/
This would allow for more easily creating shared test support projects such as for all index implementations as there would be a natural place to place such projects. Additionally the parent POMs at each group would also be a great place to manage group level build configuration. This would also simplify the root POM and make maintenance easier as configuration specific to each group could be moved into the group level poms.
In terms of artifact naming, one approach could be to use the project path to create the artifactId, so the Cassandra Astyanax module would be 'backend-cassandra-astyanax'. This would be consistent with the directory structure and would communicate the purpose of the artifact as well. Such an approach would also naturally prevent any name collisions for future modules.
Sorry for the long post but I thought it would be good to put up a more detailed straw man so we can continue the discussion.
Regards,
Samant