Bug #109520 Flatten Cluster/J source tree and update maven support

• Submitted: 3 Jan 2023 16:55
• Reporter: John Duncan
• Status: Verified
• Category: MySQL Cluster: Cluster/J
• Severity: S3 (Non-critical)
• OS: Any
• CPU Architecture: Any

[3 Jan 2023 16:55] John Duncan

Description:
Some misc. Cluster/J code cleanup:

 *  Remove vestiges of Maven support from the Cluster/J source

 *  Flatten the source tree, so that e.g. 
      clusterj-tie/src/main/java/com/mysql/clusterj/BlobImpl.java
    becomes
      clusterj-tie/src/main/BlobImpl.java

 *  Make it possible to run any Cluster/J test from autotest, using a test wrapper in storage/ndb/test/ndbapi

How to repeat:
N/A

[1 Nov 2024 17:47] John Duncan

Posted by developer:
 
I have changed the issue synopsis from "remove maven support" to "update maven support." 
Here are some various notes:

1) It was originally possible to build Cluster/J using Maven "in source," and this was used extensively in
the original development of Cluster/J.
2) In 2014 the Maven support was updated to also support "out of source" builds.
3) "In source" builds of the MySQL server are no longer supported at all.
4) The Maven support is documented at https://dev.mysql.com/doc/ndbapi/en/mccj-getting.html
5) There is a "parallel" cluster/J test suite -- a set of trivial test wrappers under clusterj-tie. In my
understanding, the only purpose of this is to enable Maven to run the test suite.
6) As far as I can tell, the primary benefit of continuing Maven support is that it allows someone to 
install Cluster/J jar files into their local Maven cache and then use them as a dependency in an 
application. This is a significant benefit, and is the reason I've revised the plan to update (rather 
than remove) the feature.
7) The convenient and reasonable way to link a Cluster/J application is with clusterj-8.x.x.jar, which 
is a "merged" jar file that contains clusterj-api, clusterj-core, clusterj-tie, plus ndbjtie, jtie,
and some needed META-INF. 
8) However, this isn't what the POM installs. It installs a "clusterj-aggregate" target that includes
separate clusterj-api, clusterj-core, clusterj-tie, clusterj-unit, and clusterj-test jar files. This 
leaves ndbjtie as a separate dependency, which must be managed using the mvn_install_ndbjtie.sh script.

I will conclude with some concrete proposals.

* Maintain support for INSTALLING cluster/j artifacts using Maven. (Note that these artifacts may have
been built via CMake).
* Do not necessarily maintain support for BUILDING cluster/j using Maven; in the end, it is okay for 
CMake to be the only supported build system.
* Remove the mvn_instal_ndbjtie.sh script. Ndbjtie will be included in the "combined" jar file. 
* Replace the current set of 6 artifacts with a new set of 3: 
   clusterj      : the "combined" jar file (for deployment; this includes ndbjtie)
   clusterj-api  : just the API (for compiling a cluster/j application)
   clusterj-test : the test suite
* Remove the set of test wrappers under clusterj-tie
* The only tests run when installing the "clusterj" target should be strict unit tests, i.e. tests
that can run without connecting to a cluster. (I don't believe any of these currently exist
in the Cluster/J code base).
* Allow installing the clusterj and clusterj-api targets WITHOUT the requirement of specifying
ndbclient.lib in Maven's settings.xml file.