Releases: maveniverse/mimir
0.3.4
Bugfix:
- daemon comm
- daemon startup
- some minor logging fixes
Full Changelog: release-0.3.3...release-0.3.4
0.3.3
Bugfix:
- daemon logging fixed
Improvement:
- daemon HELLO handshake
- file node mayLink option
- file node "name" config dropped (was unusable)
- jgroups cluster logging fixed
- socket renamed to mimir-socket (was uds-socket)
Due socket rename, pay attention to kill old daemon FIRST!
Full Changelog: release-0.3.2...release-0.3.3
0.3.2
Some cleanup and added Trusted Checksum Source.
Full Changelog: release-0.3.1...release-0.3.2
0.3.1
Parent update and a bugfix to make Mimir able to serve extra info when mvn -X
Full Changelog: release-0.3.0...release-0.3.1
0.3.0
0.2.3
Nothing big compared to 0.2.2, just made some corner cases more cleanly handled.
Changes:
- make sure we handle "simple Central direct access only"
- auto update check
Full Changelog: release-0.2.2...release-0.2.3
0.2.2
Performance fix for 0.2.1: by mistake, the UDS communication was serialized that caused slow down for MT ops like model building.
Revamped architecture to fix #4.
As a side effect, whole Mimir became Java 17+ (runtime requirement).
Maven extension now:
- loads up Mimir
- during session creation, resolves Daemon, installs and starts it up (configurable via
mimir.uds.enabled=falseinmimir.properties) - it contains two node implementations: local and uds (that communicates with Daemon via UDS)
Daemon in turn:
- contains two node implementations: local and jgroups (consumer and publisher)
- communicates via UDS with extension (UDS node delegates all the local FS work to daemon)
- publishes local to other nodes on LAN
Recommended setup: nothing, should work OOTB, but, if you have multiple network interfaces (docker, tailscale, etc), you most probably want to "help" JGroups to select your LAN interface. To achieve that, create file ~/.mimir/daemon.properties with contents:
mimir.jgroups.interface=match-address\:192.168.1.*(use what is appropriate for your LAN address). For more, see here. The mimir.jgroups.interface is alias for JGroups jgroups.bind_addr.
To use it
With Maven 4 (latest master) create ~/.m2/extensions.xml like this:
<?xml version="1.0" encoding="UTF-8"?>
<extensions>
<extension>
<groupId>eu.maveniverse.maven.mimir</groupId>
<artifactId>extension3</artifactId>
<version>0.2.2</version>
</extension>
</extensions>Works with latest Maven 3 as well, but it does not support user-wide extensions, so file above should be placed under some project .mvn/extensions.xml file instead.
IF you have docker, tailscale (or just non-trivial networking), help JGroups to select your LAN interface: create ~/.mimir/daemon.properties file like this:
mimir.jgroups.interface=match-address\:192.168.1.*(use yor LAN IP address).
And just build with Maven...
A possible scenario
On one workstation (call it W1) setup Mimir as explained above, and build something (like Maven itself) using empty local repository (-Dmaven.repo.local=...). Maven should download and start up daemon at start (only first time, afterwards Maven will start up fast), and at the build end, it should report results in line "Mimir session closed...". This populated now your (empty) local repo, but also Mimir "local" cache as well. If you look, your local repository contains ONLY hardlinked files from Mimir local cache (if both on same volume).
Next, go over to other workstation (call it W2) and again, setup Mimir as explained above and again, and also build Maven with empty local repository. This second build will NOT go to Central at all (there is no "Download..." message at all) and build is (almost) as fast as with pre-populated local repository (network dependendent). Again, at end observe the "Mimir session closed..." line.
If you open up file ~/.mimir/daemon-0.2.2.log on W1, you will see log about W2 asking for things...
Full Changelog: release-0.2.1...release-0.2.2
0.2.1
Bugfix for 0.2.0: if daemon is not present locally, and Transport must be used to resolve it, Mimir prevents to resolve itself.
Revamped architecture to fix #4.
As a side effect, whole Mimir became Java 17+ (runtime requirement).
Maven extension now:
- loads up Mimir
- during session creation, resolves Daemon, installs and starts it up (configurable via
mimir.uds.enabled=falseinmimir.properties) - it contains two node implementations: local and uds (that communicates with Daemon via UDS)
Daemon in turn:
- contains two node implementations: local and jgroups (consumer and publisher)
- communicates via UDS with extension (UDS node delegates all the local FS work to daemon)
- publishes local to other nodes on LAN
Recommended setup: nothing, should work OOTB, but, if you have multiple network interfaces (docker, tailscale, etc), you most probably want to "help" JGroups to select your LAN interface. To achieve that, create file ~/.mimir/daemon.properties with contents:
mimir.jgroups.interface=match-address\:192.168.1.*(use what is appropriate for your LAN address). For more, see here. The mimir.jgroups.interface is alias for JGroups jgroups.bind_addr.
To use it
With Maven 4 (latest master) create ~/.m2/extensions.xml like this:
<?xml version="1.0" encoding="UTF-8"?>
<extensions>
<extension>
<groupId>eu.maveniverse.maven.mimir</groupId>
<artifactId>extension3</artifactId>
<version>0.2.1</version>
</extension>
</extensions>Works with latest Maven 3 as well, but it does not support user-wide extensions, so file above should be placed under some project .mvn/extensions.xml file instead.
IF you have docker, tailscale (or just non-trivial networking), help JGroups to select your LAN interface: create ~/.mimir/daemon.properties file like this:
mimir.jgroups.interface=match-address\:192.168.1.*(use yor LAN IP address).
And just build with Maven...
A possible scenario
On one workstation (call it W1) setup Mimir as explained above, and build something (like Maven itself) using empty local repository (-Dmaven.repo.local=...). Maven should download and start up daemon at start (only first time, afterwards Maven will start up fast), and at the build end, it should report results in line "Mimir session closed...". This populated now your (empty) local repo, but also Mimir "local" cache as well. If you look, your local repository contains ONLY hardlinked files from Mimir local cache (if both on same volume).
Next, go over to other workstation (call it W2) and again, setup Mimir as explained above and again, and also build Maven with empty local repository. This second build will NOT go to Central at all (there is no "Download..." message at all) and build is (almost) as fast as with pre-populated local repository (network dependendent). Again, at end observe the "Mimir session closed..." line.
If you open up file ~/.mimir/daemon-0.2.1.log on W1, you will see log about W2 asking for things...
Full Changelog: release-0.2.0...release-0.2.1
0.2.0
Revamped architecture to fix #4.
As a side effect, whole Mimir became Java 17+ (runtime requirement).
Maven extension now:
- loads up Mimir
- during session creation, resolves Daemon, installs and starts it up (configurable via
mimir.uds.enabled=falseinmimir.properties) - it contains two node implementations: local and uds (that communicates with Daemon via UDS)
Daemon in turn:
- contains two node implementations: local and jgroups (consumer and publisher)
- communicates via UDS with extension (UDS node delegates all the local FS work to daemon)
- publishes local to other nodes on LAN
Recommended setup: nothing, should work OOTB, but, if you have multiple network interfaces (docker, tailscale, etc), you most probably want to "help" JGroups to select your LAN interface. To achieve that, create file ~/.mimir/daemon.properties with contents:
mimir.jgroups.interface=match-address\:192.168.1.*(use what is appropriate for your LAN address). For more, see here. The mimir.jgroups.interface is alias for JGroups jgroups.bind_addr.
Full Changelog: release-0.1.0...release-0.2.0
0.1.0
Initial preview release.
Full Changelog: https://github.com/maveniverse/mimir/commits/release-0.1.0