Name of automatic module 'cqengine' is unstable, it is derived from the module's file name.

[Verdoso]

Hi there,

The message in the issue title is what you gen when you use CQEngine with Java 9, and even though it is "just" a warning, it also recommends not releasing anything using it etc. etc. which makes CQEngine look bad.
I know migrating to Java >9 module system is not exactly a wlak in the park, tell me about it, but there is a simple change that can make life easier for everybody and stop that warning from appearing without forcing CQEngine to get into modul-info.java pains: The Automatic-Module-Name just needs to be declared in the manifest, so it is not derived from the file name and that's it.
The only thing necessary would be to add the following lines to the pom:

                        <manifestEntries>
                        	<Automatic-Module-Name>cqengine</Automatic-Module-Name>
                        </manifestEntries>

and that's it. To put it in context (formatted to prevent horizontal scroll):

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>2.4</version>
                <configuration>
                    <archive>
                        <!-- This is required by bnd-maven-plugin -->
                        <manifestFile>
                              ${project.build.outputDirectory}/META-INF/MANIFEST.MF
                        </manifestFile>
                    </archive>
                </configuration>
            </plugin>

becomes

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>2.4</version>
                <configuration>
                    <archive>
                        <!-- This is required by bnd-maven-plugin -->
                        <manifestFile>
                              ${project.build.outputDirectory}/META-INF/MANIFEST.MF
                        </manifestFile>
                        <manifestEntries>
                        	<Automatic-Module-Name>cqengine</Automatic-Module-Name>
                        </manifestEntries>
                    </archive>
                </configuration>
            </plugin>

AFAIK, there's no side effect except making the name used by the module system to be considered stable, thus preventing the associated warnings and avoidance recommendations.

Could this be considered? I know it's not such a big deal, but every little step in the good direction counts :).
Thanks,
D.
PS: For reference, one can check the following URL: http://branchandbound.net/blog/java/2017/12/automatic-module-name/

[Verdoso]

Oh, and I already tested it and it works preventing the warning and all tests pass. I can create a PR if necessary, but for such a small change I thought it might be overkill.
Thanks

[npgall]

Interesting. Thanks for suggesting this and letting me know exactly how to fix it!

I will make sure to include this in the next release!
(I will keep this issue open as a reminder until it's done.) Thanks!

[Verdoso]

Well, thank YOU for creating such a useful library ;). I created an initialization library that uses it +consul+hazelcast to have a clusterized, replicated "queriable" in-memory cache and I was exploring the waters to make it full Java >9 modular when I came across this.
Happy to help,
Cheers!

[codingchili]

@Verdoso how would you compare it to hazelcast IMap? Are you using hazel with consul discovery? Any benefits over the default discovery mechanism?

@archenroot might be interested in a distributed cqengine :) do you have a link?

[Verdoso]

Well, Hazelcast IMap is distributed, so queries can depend on partitions, topology... and I wanted my "indexed caches" to be local/predictable so...
And yes, I'm using Hazelcast + Consul discovery. Default discovery mechanisms are either broadcasting, not really recommended except for limited testing, and configuring a list of ips/ports to be fed to the application. You then have to care about updating the list for each environment, having non-conflicting ports for different applications...
I was already using Consul to auto-balance my apps, so I did not have to add any infrastructure to get rid of all of that and let Consul discovery find out the IPs for me and get different free-available ports for each cluster (currently having 9 independent HZ clusters in the same machines).

The implementation we are using is this: ClusteredConcurrentIndexedCollection
It is still a bit rough around the edges but it's working fine for us, so it's a starting point. Basically, it's adding a Hazelcast IMap to "replicate" the collection and pass the changes in the cluster. It's still missing some error control in corner cases but, as I said, so far, so good for our needs.

[buko]

This apparently has not been fixed. The latest version of cqengine (3.6.0) provides no Automatic-Module-Name and will generate warnings and prevent modularized publishing.

Can we add an Automatic-Module-Name for this project?

I would suggest something like com.googlecode.cqengine since Module Names generally should be a FQDN.
This would be as simple as modifying the Manifest as described in: http://branchandbound.net/blog/java/2017/12/automatic-module-name/ .