Releases/v1.5.1

[Thrameos]

Testing for release.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.18%. Comparing base (1dca470) to head (528863e).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1232      +/-   ##
==========================================
+ Coverage   87.16%   87.18%   +0.01%     
==========================================
  Files         113      113              
  Lines       10287    10287              
  Branches     4045     4045              
==========================================
+ Hits         8967     8969       +2     
+ Misses        727      726       -1     
+ Partials      593      592       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Thrameos]

@marscher I am still getting random faults in the test matrix. I am not sure if it is us or something underlaying in Python. I will likely proceed with the release as none of my local testing shows anything unstable after many runs. My general feeling is there may be an instability in some backported changes in the Python release system.

It will take a while getting the release pipeline up the date. Some of the changes in the python packaging system damaged the release system and a number of images have shifted. Hopefully I have some images by the end of the weekend.

[Thrameos]

@pelson it seems like the conversion to pyproject.toml was incomplete. None of the builds are properly under the release system. (I believe it was changed in #1133)

Unfortunately, the revised system is entirely opaque to me thus I am not sure how to proceed. Under the setup.py system it was easy to customize to include files that were outside the scope of the regular build system. (after all Python doesn't account for java files as part of the build process.) I can try to do things like moving org.jpype.jar to be under the python module, but that may break other things.

I may need to add you to azure dev cloud in order for you to see the logs. If you have a azure account that please look through the github commits to get my email and drop me a email so I can properly add you (no need to post it here.)

[pelson]

For clarity, I think an example of the failing build can be found at https://dev.azure.com/jpype-project/jpype/_build/results?buildId=1319&view=logs&j=43e8f9d5-cae4-58de-6d75-7850a2c65f3d&t=b3f58182-1c9e-5d02-648c-4672cef933aa, with a log similar to:

Generating script.
Script contents: shell
python -m pytest -v --junit-xml=build/test/test.xml test/jpypetest --checkjni --fast
========================== Starting Command Output ===========================
"C:\Windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "D:\a\_temp\340eec69-e2be-4dd1-bc57-634ec367f407.cmd""
============================= test session starts =============================
platform win32 -- Python 3.11.9, pytest-8.3.3, pluggy-1.5.0 -- C:\hostedtoolcache\windows\Python\3.11.9\x64\python.exe
cachedir: .pytest_cache
rootdir: D:\a\1\s
configfile: setup.cfg
collecting ... collected 1832 items

...

test/jpypetest/test_zzz.py::ZZZTestCase::testShutdown FAILED             [100%]

=================================== ERRORS ====================================
_______________ ERROR at setup of LegacyTestCase.testArrayItem ________________

cls = <class 'subrun._prepare.<locals>.ProxyClass'>

    @classmethod
    def setUpClass(cls):
        ProxyClass._client = Client()
>       ProxyClass._client.execute(_hook, filename, clsname, '_setUpClass')

test\jpypetest\subrun.py:141: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = <subrun.Client object at 0x00000238145A22D0>
function = <function _hook at 0x0000023812644E00>
args = ('D:\\a\\1\\s\\test\\jpypetest\\test_legacy.py', 'LegacyTestCase', '_setUpClass')
kwargs = {}, ret = None
ex = RuntimeError('Unable to find org.jpype.jar support library at D:\\a\\1\\s\\org.jpype.jar')

    def execute(self, function, *args, **kwargs):
        self.inQueue.put([function.__name__, os.path.abspath(
            inspect.getfile(function)), args, kwargs])
        try:
            (ret, ex) = self.outQueue.get(True, self.timeout)
        except queue.Empty:
            raise AssertionError("function {func} FAILED with args: {args} and kwargs: {kwargs}"
                                 .format(func=function, args=args, kwargs=kwargs))
        if ex is not None:
>           raise ex
E           RuntimeError: Unable to find org.jpype.jar support library at D:\a\1\s\org.jpype.jar

None of the builds are properly under the release system.

Unfortunately, the revised system is entirely opaque to me thus I am not sure how to proceed. Under the setup.py system it was easy to customize to include files that were outside the scope of the regular build system.

The package data inclusion rules are well defined in https://setuptools.pypa.io/en/latest/userguide/datafiles.html#include-package-data. Since we have a MANIFEST.in, we should be getting the desired includes. https://github.com/jpype-project/jpype/blob/master/MANIFEST.in

Perhaps this means we are not building the JAR in the first-place... (again, this could have been a change by me in #1133). On the Azure side of things, I don't have much knowledge and it looks like I can't download the wheel as an artifact to inspect. I will take a look to see if I can reproduce the problem locally.

[Thrameos]

You should be able to get all the artifacts from build. I believe to went wrong executing the source dist which is supposed to build the jar and collect all the distibuted sources. If something is missing from the step then everything downstrwam will fail.

The procedure I would use would be pull the source artifact and inspect it. The disable tge rest if the release build (to save time or ypu can end up with 10 failed builds queued up), then trigger a new release with changes until tge source dist succeeds.