Hi! I've added you as a maintainer of the project. Happy if you merge it.

I had a look and found nothing problematic imo. Too bad you had to resort to reflection. Maybe it's something fixable in the future ? Anyway it's good for now.

Just a quick question: it's working without updating the warpy dependency ? If yes, I'm happy.

Hi! I've added you as a maintainer of the project.

Thank you a lot!
In the future I would like to avoid merging things without opening a PR, however. If that is ok for you, I'd like to keep your check as 4 eyes are better than 2 :D
Even just for a quick glance!

Happy if you merge it.

There are only a couple of things I'd like to have your full ACK:

• by moving to kotlin, I had to move the publishing to Maven repositories. Do you reckon it's alright? I don't have much experience with it, sorry!
• i updated the version from 0.3.* to 0.4.*, is that okay

Too bad you had to resort to reflection. Maybe it's something fixable in the future ? Anyway it's good for now.

Believe me, I've tried to avoid it but for now there is no other option. An likely nothing for the whole QuPath 0.6.* version.
The problem is that we should be able to read the rotation value (but also other transformation like Zoom, technically) from the metadata of the ImageServer builder.
However ImageServerBuilder interface is really... static in QuPath. Its structure is used in saving states and it makes every change a delicate operation.
Add to that the fact that very few projects (apart from ABBA) would use this feature as it's necessary only when you need to apply a transformation to a coordinate system in order to lazily import some annotations drawn by another program.

I don't see this being a short-term workaround :\

Just a quick question: it's working without updating the warpy dependency ? If yes, I'm happy.

Yes, as of now it's depending on warpy 0.3.1.
It's actually bundling the .jar extension with warpy dependecy included. On this regard, do you think we should update the installation instructions so that they don't require you to explicitly install warpy as well?
I also noticed that you are developing warpy 0.4.0 with QuPath 0.6.* support. Should I update to that version once it's available?

Thank you!

I had to move the publishing to Maven repositories

What do you mean by that ? Everything was published to scijava maven before:

https://maven.scijava.org/#nexus-search;quick~qupath-extension-abba

Is it not published now ? Or is it published on central instead of scijava ?

i updated the version from 0.3.* to 0.4.*, is that okay

Sure; makes perfect sense since it's not compatible with QuPath 0.5 anymore.

I don't see this being a short-term workaround :\

Alright.

It's actually bundling the .jar extension with warpy dependecy included.

Ah, this is not great indeed. It's a fatjar ?

I had to move the publishing to Maven repositories

What do you mean by that ? Everything was published to scijava maven before:
https://maven.scijava.org/#nexus-search;quick~qupath-extension-abba

Sorry, I explained myself badly. I meant that i moved and change the script to publish to scijava maven and I am not 100% sure it is correct until we'll run the CI/CD workflow here on github

Is it not published now ?

It is not, yes

It's actually bundling the .jar extension with warpy dependecy included.

Ah, this is not great indeed. It's a fatjar ?

Yes, warpy dependency is added with implementation("qupath.ext.warpy:qupath-extension-warpy:0.3.1"), not with shadow("qupath.ext.warpy:qupath-extension-warpy:0.3.1"). QuPath suggest to use the latter method just for qupath dependencies.
Actually, the current revision of build.gradle is also adding warpy with implementation() and not with shadow(). Doesn't that mean that, as of now, qupath-extension-abba is a fatjar?
Why do you prefer avoiding fatjars? Doesn't that increase the chance of bad behaviours due to mismatched versions of the extensions?

just as a clarification: the fatjar is built only with ./gradlew shadowJar. If we wished to keep warpy extension a forced dependency (thus breaking QuPath extension updater), then distributing the jar result of ./gradlew build is enough!