[hibernate-dev] HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules

Picking automatic module names for Hibernate Search isn't going to be straight-forward as our two main jars (hibernate-search-engine & hibernate-search-orm) suffer from split package among them. We can't really fix the split package problem without breaking all users, so if we want to consider that, we can debate it but that will need to happen at another round as we're doing a minor release, so let's focus on: # Which names to pick # Should we pick the names at all # Which modules should have a name For a great background on the possible strategies and pitfalls I recommend reading Stephen Colebourne's blog on this subject [1]. He persuaded me there are good reasons to use the "reverse DNS, the top level package", however since we have the split package problem we can't simply go with that. Still, we can respect the principles he recommends with a small variation. It's fair to assume that the `org.hibernate.search` prefix is "ours"; since the nature of the suggestion is focused on making sure there are no misunderstandings in the community about which names you can choose - as there is no central authority making sure module names aren't clashing - we should be fine within Hibernate projects with any `org.hibernate.X` prefix, as long as we coordinate and reach an agreement on this list. So, I propose we use: Engine module: - org.hibernate.search.engine ORM integration module: - org.hibernate.search.orm JGroups, JMS backends: [ no automatic module name ? Excepting some "guidelines" in the JMS module, these are not public API so nobody would benefit from it - also we think we might want to phase out the name "backend" in the future ] Elasticsearch integration module [hibernate-search-elasticsearch.jar]: - org.hibernate.search.elasticsearch Elasticsearch / AWS security integration: [ no automatic module name: no public API ] Serialization / Avro [ no automatic module name: no public API ] WDYT? We could also pick names for the ones which I've listed as "no public API" but I see no point: as we're only assigning an "Automatic Module Name" we won't be able to explicitly state that the other modules depend on these. So nobody will use them, and things are a bit in flux anyway in this area because of Hibernate Search 6 plans. Another optional altogether: since we have split packages which we'll have to resolve before we can actually transform these into fully fledged modules, I think an acceptable position is also to say we won't be publishing any automatic module name yet. Personally I'm inclined to go with the names suggested above, at least some others can start making baby steps, even if it's not all there. # What I don't like: For one, that the typical application will need to import both `org.hibernate.search.engine` and `org.hibernate.search.orm`, and likely more as well (e.g. Elasticsearch API, Lucene API module is coming, ..). Maybe similar to BOM's today we could publish a module which statically imports multiple of these, that could be nicer to use but we risk needing to publish (and document) one for each of a selection of combinations. So let's not start with such things yet. Thanks, Sanne [1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html