Tags

* Dropped support for JDK 1.8 and added JDK 17 and 21
* No longer tested on CC7, switched to EL9

* Remove the behaviour of the register, unregister, install and uninstall commands, as well as the `pkg` argument in the Manager constructor - they are superseded by the normal entry-point registration process
* Add strict type checking to the project, and mark cmmnbuild-dep-manager as typed

* Correct the handling of project name and package name. It is now only possible to register a module which is discoverable by package metadata

* Module versions are now determined by metadata (`dist-info/METADATA`) instead of importing them and accessing the `__version__` attribute.
   * This is more reliable, and means that you no longer need to encode the version into the entrypoint when declaring a project to be JAR dependent (thus allowing projects to be pyproject.toml only).
   * Subtly, this means that it is no longer possible to "register" an importable but uninstalled module - given the prevalence and simplicity of editable installs, this is considered to be a reasonable approach (and means that in the future, the removal of `register` and `install` is likely)

- add BOM support for GradleResolver

* Minimum JPype version 1.5 (due to need of improved threading behaviour since 1.4. Nominally could have been 1.4 constraint)
* When starting the JVM on a non-main thread, ensure to attach the thread as daemon, as per https://github.com/jpype-project/jpype/issues/1169.
* If groupId is not specified, we raise on the client side (it was already the case that we raised on the server side)

* Ensure that downloads raise if they get a non successful return code
* Minimum JPype version now 1.3

* Upgrade gradle wrapper, enabling support for newer JDKs

* Improve the error message when the cbng-web server responds unexpectedly (e.g. a 4xx or 5xx error)
* Minimum supported version of Python increased to Python 3.7

* Allow control of the JVM startup arguments
* Set the default max heap size of the JVM startup to the lesser of 8GB or 33% of the system's memory (particularly relevant for PyTimber)
* Added a [``cmmnbuild_dep_manager.Manager().jvm_required()``](https://acc-py.web.cern.ch/gitlab/scripting-tools/cmmnbuild-dep-manager/docs/stable/api/cmmnbuild_dep_manager.Manager.jvm_required.html#cmmnbuild_dep_manager.Manager.jvm_required) to allow libraries to resolve dependencies (if necessary) and start the JVM in a single step

* Allow control of the JVM startup arguments
* Set the default max heap size of the JVM startup to the lesser of 8GB or 33% of the system's memory (particularly relevant for PyTimber).

## New Features

* cmmnbuild-dep-manager can now manage type stub generation for JPype based Java code.
  A command, ``python -m cmmnbuild_dep_manager stubgen`` was added to allow this from the command line.
  This functionality is an optional extra and must be enabled with ``pip install cmmnbuild-dep-manager[stubgen]``.
  With generated stubs, tools such as ``mypy`` can do static analysis on your code and detect incorrect usage of a Java library accessed with JPype.
  A significant benefit is that you will also get tab completion and an improved development experience in an IDE such as PyCharm.
  See Michi's PjLSA talk at https://indico.cern.ch/event/938422/#4-pjlsa-jpype for a demonstration of the concept.

* The CBNG JAR resolution implementation has been rewritten to use the [new cbng-web service](https://gitlab.cern.ch/acc-co/devops/cbng/cbng-web) running at https://acc-py-repo.cern.ch/cbng-web-resolver/resolve/productxml.
  The new service mirrors the GET & POST behaviour of the previous CGI based cbng-web service.
  * This new implementation supports the ability to resolve the Java environment without necessarily downloading the JARs, and allows ``cmmnbuild-dep-manager`` to download the individual JARs directly from ``artifactory.cern.ch``.
     * Downloading of JARs is now done in parallel, and is able to skip downloading of JARs that it has already downloaded previously.

* ``cmmnbuild-dep-manager`` now has the ability to resolve a Java environment to a file, and to install/download JARs defined in the file; this is good for versioning your environment, much like a ``requirements.txt`` (this is the mechanism employed by [acc-py-deploy](https://gitlab.cern.ch/acc-co/devops/python/acc-py-deploy)). See [``Manager.lockfile_generate``](https://acc-py.web.cern.ch/gitlab/scripting-tools/cmmnbuild-dep-manager/docs/stable/api/cmmnbuild_dep_manager.Manager.lockfile_generate.html#cmmnbuild_dep_manager.Manager.lockfile_generate) and [``Manager.lockfile_install``](https://acc-py.web.cern.ch/gitlab/scripting-tools/cmmnbuild-dep-manager/docs/stable/api/cmmnbuild_dep_manager.Manager.lockfile_install.html#cmmnbuild_dep_manager.Manager.lockfile_install) for more details.
  Note that it is not yet possible to generate a lockfile from an *existing* environment.


## Bug fixes

* There are several known issues with JPype v1.x which are addressed with this release of ``cmmnbuild-dep-manager``
  * [An issue with numpy/OpenBLAS & JPype/JNI](https://github.com/jpype-project/jpype/issues/808) interacting poorly and causing a segmentation fault when doing linear algebra in numpy is worked around ([scripting-tools/cmmnbuild-dep-manager!69](https://gitlab.cern.ch/scripting-tools/cmmnbuild-dep-manager/-/merge_requests/69))

  * An issue with Java libraries which don't correctly clear up non-daemon threads upon termination is worked around in this release of ``cmmnbuild-dep-manager`` by calling ``System.exit`` a defined period after the final termination of Python itself. This is particularly relevant for JAPC users, where some connections are being held indefinitely unless forced to stop in this way (https://issues.cern.ch/browse/JAPC-1014).

  * An issue where Python & Java aren't cooperating well with interrupt signals has been addressed by adding the ``-Xrs`` flag to JVM startup. This flag was previously set for JPype ``v0.x`` and means that libraries such as PyQt are now able to be interrupted as expected. See [scripting-tools/cmmnbuild-dep-manager!70](https://gitlab.cern.ch/scripting-tools/cmmnbuild-dep-manager/-/merge_requests/70) for more details.

* The instantiation of a Manager will no longer configure the root logger, and instead only sets up a log handler for ``cmmnbuild-dep-manager`` logs if the root logger has not been previously configured. ([scripting-tools/cmmnbuild-dep-manager!52](https://gitlab.cern.ch/scripting-tools/cmmnbuild-dep-manager/-/merge_requests/52))

* ``cmmnbuild-dep-manager`` will now correctly unregister packages which have been manually registered and which are unimportable ([scripting-tools/cmmnbuild-dep-manager!55](https://gitlab.cern.ch/scripting-tools/cmmnbuild-dep-manager/-/merge_requests/55))

* The minimum version of ``JPype`` is now 1.1, and significant test coverage has been added to ensure that ``cmmnbuild-dep-manager`` works with the supported versions.

* API documentation has been added at https://acc-py.web.cern.ch/gitlab/scripting-tools/cmmnbuild-dep-manager/docs/stable

* The module ``cmmnbuild_dep_manager.cmmnbuild_dep_manager`` has been removed as it is redundant and incorrect. ``Manager`` can be accessed from ``cmmnbuild_dep_manager.Manager``.

A release candidate for v2.8.0.

* ``python -m cmmnbuild_dep_manager`` CLI is now managed by argparse - this results in better help, and a more standard feel to the interface
* The CWD is no longer added to the JAR path automatically (https://gitlab.cern.ch/scripting-tools/cmmnbuild-dep-manager/-/merge_requests/37)
* Manager.imports context manager now correctly tidies up even if there is an exception raised inside the context (https://gitlab.cern.ch/scripting-tools/cmmnbuild-dep-manager/-/merge_requests/46)
* The Manager constructor no longer *always* hits the cbng-web service (https://gitlab.cern.ch/scripting-tools/cmmnbuild-dep-manager/-/merge_requests/48)

* The ``PYTHONNOUSERSITE`` environment variable (and the ``-I`` and ``-s`` python flags) is now honoured when determining whether to use ``$HOME/.local/lib/python3.*/site-packages`` as a source for JARs. This location is strongly discouraged, but follows Python's lead and will use it if the directory exists and the flag is not set. The documentation of CPython itself has been enhanced following the discovery of an error regarding this issue: https://bugs.python.org/issue41376.
* Some initial work to support JPype v1.0 has been undertaken, with improvements already integrated into cmmnbuild-dep-manager for the following:
  * Improved handling of ``KeyboardInterrupt``, which was no longer being raised by JPype with the ``-Xrs`` JVM argument. https://github.com/jpype-project/jpype/issues/813
  * Investigated the fact that JPype holds on to running JVM threads (daemon & user), often resulting in Python not exiting correctly. Issue reported and being tracked at https://github.com/jpype-project/jpype/issues/813.
  * JPype1 0.x effectively no longer supports ``Python >=3.8.4``. The ``setup.py`` metadata was updated to reflect this fact.
* Fixed a few bugs with function signatures which were using mutable defaults. ``Manager.start_jpype_jvm(..., extra_jars=)`` and ``Manager.class_path(..., extra_jars=)`` are affected.

- first version of the import system (experimental/unsupported until JPype 0.8)

* Update recommended registration mechanism to use entry_points defined in the setup.py/pyproject.toml. This allows packages depending on cmmnbuild-dep-manager to be installed as wheels without the need to execute code at install-time.
* Automatic versioning through setuptools_scm
* cmmnbuild-dep-manager packaged as a wheel
* Improved package metadata, including a long-description for improved context on pypi.org
* Updated documentation and maintainer information