feat: Add JAR files as runtime dependencies to Python package.

[mheggelund]

Aims to fix problem where jneqsim package became too large

• Add JAR files as runtime dependencies intead of bundled JAR files

[matsklevstad]

note: in order to run a specific test pypi version in NeqsimAPI:

uv remove jneqsim


uv add --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple "jneqsimsmall==3.1.2" 
# you might get an error but it will take some minutes before the package is available 
# as test.pypi has some kind of cache


uv lock


docker compose up --build

(optional, try to remove the whole .venv aswell: rm -rf .venv )

[Copilot]

Pull request overview

Copilot reviewed 14 out of 16 changed files in this pull request and generated 11 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 15 out of 17 changed files in this pull request and generated 13 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Breaking change: Publishing to TestPyPI instead of PyPI. This appears to be a testing/development change that shouldn't be in a production release. The original code published to PyPI, but now it publishes to TestPyPI with a personal token (TEST_PYPI_TOKEN_MAOHE). This should either be reverted to publish to PyPI, or this should be documented as a temporary testing workflow.

Suggested change

	- name: Publish package to TestPyPI
	run: hatch publish -r test
	env:
	HATCH_INDEX_USER: __token__
	HATCH_INDEX_AUTH: ${{ secrets.TEST_PYPI_TOKEN_MAOHE }}
	- name: Publish package to PyPI
	run: hatch publish
	env:
	HATCH_INDEX_USER: __token__
	HATCH_INDEX_AUTH: ${{ secrets.PYPI_TOKEN }}

[MarcusDragsten]

We will change this before merging!

[Copilot]

JVM lifecycle issue: The code checks not jpype.isJVMStarted() to start the JVM, but JPype JVM can only be started once per process. If the JVM start fails (line 50), subsequent imports of this module won't retry starting the JVM since the check happens at module import time. Also, if another part of the code starts the JVM before this module is imported, the JAR won't be added to the classpath. Consider handling these edge cases or documenting the expected usage pattern.

[MarcusDragsten]

This is the only place we start the JVM