Gradle Runner

[Stefterv]

Tasks

• Improve visual feedback on what is happening within Gradle
• Improve speed and reliability
• Allow exporting applications from the PDE with gradle
• Preliminary cli support
• Fix Beta screen (Removed all UI changes)
• Gradle Plugin should be tested on every platform
• Support Windows and Linux (Snap) better
• Gradle Service: Avoid adding build.gradle.kts files to examples
• Separating the stdin/err from Gradle and from Processing
• Threading null pointer exception
• Gradle Plugin: Doesn't work if no libraries are installed / library folder is missing
• Gradle Plugin: Build-in libraries not scanned
• Gradle Plugin: Store library scan metadata globally
• Gradle Runner: Add built in repo to settings.gradle.kts when running the Gradle Runner with DEBUG
• Gradle Plugin: Another rewrite of adding the deps to be compatible with Gradle 9
• Gradle Plugin Example: Sketchbook path is not set by default
• Gradle Plugin: Distribution CI/CD (seems straightforward) (Blocked until merge)
• Test offline functionality
  • Embedding Gradle Distribution? (Adds another 150mb to dl)
  • Feedback Gradle being downloaded
• Tests
  • Sketch: Disabling AWT
  • Sketch: Processing Editor Location
  • Sketch: Hiding stop
  • Sketch: Present
  • Sketch: Fullscreen
  • Sketch: UIScale
• Added line-highlighting where possible
• Defining a plugin interface
  • Registering a callback for the debugger
  • Registering a callback for the pipe
  • Registering a callback for creating the build.gradle.kts?

Current issues

• Windows: does not like the way the System.err and System.out are routed
• Windows: some issue with the native binaries causing running to crash
• macOS: Exported application (Could not find agent library jdwp on the library path)
• macOS: Unsigned jar in distributable (race condition?)
• Windows: Library class not found errors
• Windows: Example folders are readonly causing gradle to crash (using --build-file argument for gradle does not work)
• Windows: Failed Gradle Task does not report errors
• Windows: Library examples seem to not be marked readonly
• Windows: Scan Libraries task fails on contributed examples
• Windows: Provider.forUseAtConfigurationTime warning
• Windows: OpenJDK stays active after killing the PDE
  • Windows: This even prevents a library from being uninstalled because the file is still in use
• Rename windres doesnt run
• Linux: P2D and P3D renderer broken (Incorrect JOGL dependencies)
• Snap: Not sure what is wrong yet
  • Home Directory not accessible for Gradle distribution download

Functionality

Gradle Plugin

• Run Sketches
  • macOS
    • arm (✅)
    • x86 (⏳)
  • Windows
    • x86 (✅)
  • Linux
    • arm (⏳)
    • x86 (✅)
    • Snap (⏳)
• Export applications
  • macOS
    • arm (✅)
    • x86 (⏳)
  • Windows
    • x86 (✅)
  • Linux
    • arm (⏳)
    • x86 (✅)
    • Snap (⏳)
• Including libraries
  • macOS (✅)
  • Windows (✅)
  • Linux (portable ✅, snap ❌)

Runner

• Run Sketches (P2D)
  • macOS
    • arm (✅)
    • x86 (⏳)
  • Windows
    • x86 (✅)
  • Linux
    • arm (portable ✅, snap ❌)
    • x86 (portable ✅, snap ❌)
• Run Examples
  • macOS
    • arm (✅)
    • x86 (⏳)
  • Windows
    • x86 (✅)
  • Linux
    • arm (⏳)
    • x86 (portable ⏳, snap ⏳)
• Including libraries
  • macOS (✅)
  • Windows (✅)
  • Linux (portable ✅, snap ❌)

[Stefterv]

DRAFT: Forum post

Feature Preview: Gradle Runner

For the past few months I have been working on a new internal build system for Processing that uses Gradle instead of the Eclipse compiler and recently I got it to a state where it is testable by others.

To try the new internal gradle runner (aka the modern build system) download my testing version of Processing here:
[Download TBD]

Then go into the settings and select use modern build system in the running section. I have added a quick console reminder to indicate which version of the build system is in use.

Why the feature preview?

Of course changing the internal build system of Processing is going to be a monumental change and I am very aware that it will break something. I will outline some of the reasons for this change below, but I would like to work with the Processing community to make sure we can make this transition as smooth as possible.

⚠️ Known issues

• Internal libraries (dxf, svg, serial, ...) are not yet included.
• P2D and P3D do not yet work on Linux

How to report issues?

...

Why Gradle?

In the past few months developing for Processing and talking to wider community one thing was a common occurrence, people used Processing at the beginning of their journey but ultimately hit a wall in their growth that made them abandon the coding language for something more advanced. This is hopefully a foundational step in changing that.

By using Gradle internally we are much more aligned with the wider Java ecosystem, as you can see, the internal Gradle runner will add a build.gradle.kts and settings.gradle.kts file to your sketches. This means you sketches will become fully fledged standalone Gradle projects, that can be opened in any editor that supports Gradle.

On the topic of the Java ecosystem, moving to Gradle means that we will be able to integrate Maven Central (and other maven repo) dependencies in our sketches. No more downloading jars from Maven and putting them in the code folder, add the dependency in the build.gradle.kts file and viola your java library will be available to your Processing sketch. (The plan is to add this functionality to the UI at a later stage)

Also it will mean that modifying the build process for individual sketches will be possible. I know a couple of people here that are interested in JavaFX (looking at you svan and glv). In the future that will be as easy as adding the JavaFX plugin to the build.gradle.kts. Of course that is not all, I also foresee that there might be future libraries/contributions that will modify the build system in small ways to provide some setup or easy of use.

Another reason is that this change means that the build system that Processing uses will be modular, so it can be reused by others for their own purposes. The previous build system was very coupled to the Processing editor and to run Processing sketches for example in another editor, you were required to use the CLI and it was very hard to add a step in-between.

Finally it means unification, the same system that we use to build the Processing Editor is the same system we use to build Processing Sketches. This means that any improvements we make for distributing Processing also apply to Processing Sketches. One very nerdy note that I like to mention, that technically it is possible to build Processing within Processing with this build, add processing4.pde to a clone of the repo, open it in the PDE and click run, it will open another instance of Processing.

So why this post?

I would like you to try the feature preview build and let me know if your sketches work as expected. Also this feature ended up being much more backend focused than originally imagined so I hope that what is happening is clear (I had originally designed some new UI for this as well). I have not yet had time to test all of the libraries that Processing has to offer for example and I am 100% sure that there is something I have missed, some use case that is outside of my view of the use of the software.

What is next?

if we do not find any glaring issues with this somewhat public release, we will merge these changes into Processing and it will be included into an upcoming release behind the feature toggle in settings. We will write documentation and provide some insights on how this new build system could be used by the community. Then at some point in the future we will hopefully switch to this new build system by default, deprecating the old system with hopefully no (or at most a few) regressions.

I’d love for you to try this preview and share feedback. Whether your sketches work perfectly or break in strange ways, your input will help us improve it before it becomes a regular feature in Processing.