[Radiance] Provide Maven artifacts

[michaelbull]

https://jitpack.io/#kirill-grouchnikov/radiance/master-SNAPSHOT

Jitpack is working thanks to the new project using Gradle.

[kirill-grouchnikov]

It's probably going to be something like

org.pushingpixels.radiance:substance or :radiance-substance

[michaelbull]

Actually nevermind it doesn't work because the subprojects depend on version 1.0.0 - if you were to tag the repository at 1.0.0 then Jitpack would work great for the interim.

[kirill-grouchnikov]

The version is 1.0.00-dev at the present, and will become 1.0.00 later in second half of 2018 when it's released.

[kirill-grouchnikov]

Group ID org.pushing-pixels has been registered - https://issues.sonatype.org/browse/OSSRH-40381

[brunchboy]

I am delighted to see these projects are alive and making progress! I used an old fork of Substance (insubstantial) to provide a dark (Raven) look and feel for my Beat Link Trigger project, which started as a proof of concept of how to use my Beat Link library, but which has turned into a widely used tool for synchronizing visuals and lasers to DJ performances. Sadly, the LAF crashes under Java 9 and 10, so I am very much hoping to be able to replace it with the Radiance Substance artifact as soon as you can get snapshots into Maven Central for my Clojure builds to pull.

[brunchboy]

And I have been able to set up a temporary local-to-project Maven repository containing the latest release jars of Substance and Trident, so that I could validate that the current code does not crash under Java 10, fix more of my own issues, and start working on tweaking my UI to look better with your current look and feel. W00t!

[kirill-grouchnikov]

Thanks for verifying that the old crash in the forked project is not happening under the latest Substance build. I am regularly testing the development version under Java 9 / 10 and moving it forward, but of course if there are any issues, I'll be happy to take a look.

As far as the dependencies go, under Radiance there will be an additional dependency for Substance - Neon (which is also part of Radiance going forward).

[brunchboy]

Interesting, although surely once you have the Maven artifacts published, you won’t need to tell people like me such things, because I will simply add something like:

[org.pushingpixels/radiance-substance "1.0.0"]

to my :dependencies vector in project.clj and Leiningen/Maven will pull in all of the transitive dependencies for me. That’s the beauty of the Maven ecosystem! 😁

I do seem to have found one small issue, I have some icon buttons which render fine when enabled, but when disabled, only draw the top-left quarter of the icon. Should I open an issue tagged [Substance]?

[kirill-grouchnikov]

Top-left quarter is a strong indication of something going amiss with high-DPI aware rendering of content on a high-resolution screen. Please open a new issue with a complete test app that shows this happening under the latest development version of Substance. This may be in the core button UI delegate, or maybe on the app side of things (in which case there are APIs in NeonCortex to do proper scaling).

[brunchboy]

Yes, I thought it might have to do with high-DPI, so I tried dragging the frame onto my non-4K monitor, but that didn’t change anything. But that doesn’t prove anything either, since high DPI was definitely a factor on the screen where it was originally rendered.

Unfortunately, I don’t think it is going to be practical for me to give you a test application that will be useful to you, because it will require the Clojure language, the seesaw Clojure-Swing binding, and then my button. Perhaps this should be my sign that it is time to ditch Swing and build a web interface instead, which will help my users who want to run Beat Link Trigger on a headless Raspberry Pi, and control it remotely from a laptop in the lighting booth.

[brunchboy]

Ok, I can report that the problem goes away if I stop using the Substance Raven look and feel. The gear draws fine in both button states in the system default look and feel. I will try to see if I can find time to see if the problem is reproducible in a simple Java program, although this is stemming from my attempt to upgrade a side project of a side project to Java 10, so I don’t have a ton of cycles for it.

[kirill-grouchnikov]

Java 9/10 have introduced built-in core support for high-resolution displays. Substance is not using that mechanism as it still supports Java 8. Without something that I can reproduce locally, there's not really much I can do.

[brunchboy]

Understood. I’ve reached the point where I have failed to reproduce the problem using the radiance-*-0.9-dev.jar files and a simple Java class, and am about to try the final non-Radiance jars which Beat Link Trigger is currently using for comparison purposes.

[brunchboy]

All right! I can reproduce the problem with substance-8.0.2.jar and trident-1.5.0.jar but not with the radiance-* versions, so I am not going to open an issue. Instead I will switch to testing against the Radiance versions. Sorry for the false alarm!

[kirill-grouchnikov]

Thanks for testing under the dev bits. That whole area is still evolving (borrowing major chunks from Intellij IDEA) as the underlying platform support is progressing.

[brunchboy]

All right, I’ll keep that in mind! I just switched my BLT build to embed those three Radiance dev jars, and it came up fine, with correctly rendered icon buttons. How often should I check for new dev drops? And I will definitely let you know if I run into anything else. Thanks for your help, this is a huge undertaking you are working on, I very much appreciate all your efforts to update it.

[kirill-grouchnikov]

As far as Substance goes, the bigger pieces that I have planned for the first release of Radiance (splitting icon/font stuff into Neon, switching Flamingo on top of Substance) are done. There may be smaller tweaks here and there, but it should be pretty stable.

Most of the focus in the next couple of months will be on Flamingo, to modernize the visual appearance of the ribbon component, as well as to bridge the functionality gap that has opened up in the last few years.

You're welcome to click that "Watch" button to see the changes going in. I'm not the best at keeping the changes compartmentalized, so more often than not a single commit would be touching multiple pieces across Radiance.

[brunchboy]

Might you consider starting to deploy snapshot builds to Maven Central when you update the drops folder? It could be a way to shake down the Maven build infrastructure, and would make it easier for people who plan to use your Maven releases to stay up to date before your first actual release, and then once you have done that, all we need to do is switch our project configuration to point at the actual release artifact rather than the snapshot one.

[kirill-grouchnikov]

In the interest of saving time and not falling asleep, what's the recommended tutorial these days to set up the snapshot builds? I'm looking at the absolute minimal number of steps involved to change the top-level build.gradle and the module-specific build.gradle files. Typing in Sonatype user / password in command line for every upload is fine with me.

[brunchboy]

I am such a reluctant Maven user myself (I mostly consume the artifacts using Clojure-based build tools which are a lot easier to use) that I’m not the person to have a great answer for you, and if it would force you to type your credentials that often, I respectfully retract my request. I did get things set up on my Mac so that my keychain manages automating that for me, but I’d be hard pressed to walk you through that.

I believe that all you need to do is set the pom.xml to have a version number that ends in -SNAPSHOT and the build tools will operate in snapshot mode, letting you replace already-deployed artifacts and having consumers find the latest ones when they rebuild. But again, if it’s going to be that much of a hassle to actually upload them, please focus your time instead on finishing the release, and I will continue using git and manually deploying into my local repo when I want to build against newer drops.

[kirill-grouchnikov]

https://oss.sonatype.org/content/repositories/snapshots/org/pushing-pixels/ is very preliminary. Still need to figure out the artifact naming scheme, as well as only upload snapshots of "core" modules (no demo stuff).

[brunchboy]

Wow, it looks like you have made great progress with this! Please let me know when you think the artifact naming is settled down enough that you would like me to try building against your snapshots rather than the drop folder in the repository, and I would be happy to do so. I have been making a bunch of breakthroughs in my related open source projects as well (the final one of which depends on Radiance), so this is great timing.

[kirill-grouchnikov]

Snapshot dependencies for core modules should be all correct now.

For testing purposes, use this:

repositories {
    maven { url "https://oss.sonatype.org/content/repositories/snapshots" }
}

dependencies {
    implementation 'org.pushing-pixels:radiance-substance:0.9-SNAPSHOT'
}

[kirill-grouchnikov]

All module names are in the form of radiance-XYZ. The primary core modules are substance and flamingo. There are also neon, trident, ibis, spoonbill, kormorant and substance-extras.

I'll clean up the build scripts and upload them shortly. Next step is to switch to 1.0-SNAPSHOT since that seems to be the convention that will signify to Sonatype that snapshot folders can be cleaned up when the final 1.0 build is published.

[brunchboy]

That’s wonderful, thank you! I have switched over to building against your snapshots on Sonatype, and it is working great. And you’re right, the convention is that while working on releasex.y, the candidate builds are deployed as x.y-SNAPSHOT, and can be replaced with newer artifacts as development proceeds. For client projects, Maven will check once per day (unless the project configures it to refresh more often) to see if a newer snapshot is available, and download that. But once you are ready to make the final release, you remove the-SNAPSHOT suffix, and that artifact goes to Maven Central, and is immutable, so it can be safely used in other released products. (In fact, if you try to build an artifact that contains any snapshot dependencies, the build will fail unless your own version is also marked as a snapshot.)

Since my project is written in Clojure and uses Leiningen as its build tool, my configuration is slightly different, but analogous. I needed to add this entry to enable the snapshot repository (this replaced an entry which pointed to the filesystem repository within my project where I had been manually deploying files from your drop folder):

:repositories {"sonatype-snapshots" "https://oss.sonatype.org/content/repositories/snapshots"}

And then I simply mention the Radiance dependencies I actually use inside my :dependencies vector:

[org.pushing-pixels/radiance-neon "0.9-SNAPSHOT"]
[org.pushing-pixels/radiance-substance "0.9-SNAPSHOT"]
[org.pushing-pixels/radiance-substance-extras "0.9-SNAPSHOT"]
[org.pushing-pixels/radiance-trident "0.9-SNAPSHOT"]

Just let me know when I need to switch to 1.0-SNAPSHOT and I will. (And, of course, to the release version once that is available too. 😀)

Thanks again for doing this, it will make it so much easier for me to keep up to date!

[kirill-grouchnikov]

-neon and -trident do not have to be explicit, as far as I understand.

-substance lists them as its own dependencies, so they should be brought in during the build process. You can kind of say the same for -substance-extras as it brings -substance as its dependency, but it feels that it would be weird to not list the core -substance as one of your dependencies.

By the way, which parts of substance-extras are you using? I find myself not really spending a lot of time and polish on things there like skins or painters.

[brunchboy]

Good point. I kind of had to be explicit about all of them when I was managing copies of them inside my own project, but it would be a good test of the transitive dependencies to pull in just substance and substance-extras. I will try that now. The only thing I am using from substance-extras is SubstanceCrosshatchWatermark because that made a great background for RavenSkin in my UI.

[brunchboy]

You’re correct. I removed the pushing-pixels hierarchy from my Maven cache, removed all but the substance and substance-extras dependencies (I agree, it feels weird to mention the extras without substance itself), and ran Leiningen, and it pulled in all four packages.

[kirill-grouchnikov]

There's no official tracker for 1.0 release, so might just as well post an update here. The plan is to finalize 1.0 during September or at the latest early October.

[brunchboy]

Thanks for the update! I’ve run into plenty of meaty issues to keep me busy before making my own release, so this is very comfortable. And I very much appreciate having some idea of what to expect. You seem to have been quite busy on this huge collection of libraries.

[kirill-grouchnikov]

Java 11 is scheduled to be released Sep 25 Kotlin 1.3 is most probably going to be released the week of CotlinConf which is Oct 4

So for now Radiance 1.0 is planned for the week of Oct 8

[kirill-grouchnikov]

Kotlin 1.3 is still 1-2 weeks out. Radiance 1.0 will not be tied to that anymore.

[kirill-grouchnikov]

The binaries for 1.0.0 have been signed, uploaded and staged. Will be released a bit later tonight if everything goes well.

[brunchboy]

Awesome! You are ahead of me… I have been finding loose ends I want to tie up this weekend before making my next stable release of Beat Link Trigger.

[kirill-grouchnikov]

1.0.0 artifacts are live

[kirill-grouchnikov]

https://github.com/kirill-grouchnikov/radiance/blob/master/docs/dependencies.md

[brunchboy]

Rather than listing a subset of the different build tool dependency formats and using x.y.z like that, you can embed badges like this which show the latest release version, and when clicked on, take you to the Maven Central page showing the proper include formats for an even larger range of build tools and languages:

radiance-neon:

Here is the source for the above:

[![Maven Central](https://maven-badges.herokuapp.com/maven-central/org.pushing-pixels/radiance-neon/badge.svg)](https://maven-badges.herokuapp.com/maven-central/org.pushing-pixels/radiance-neon)

[kirill-grouchnikov]

Thanks for that snippet. https://github.com/kirill-grouchnikov/radiance/blob/master/docs/dependencies.md has been updated.