A while ago I proposed to tackle the gradle build file and break it down, I've done this kind of work in other projects though not with such a huge file. The effort was halted due to Johan's approach with using the JDK's build system. I don't know how far along that is.
On Tue, Apr 14, 2026 at 8:28 PM Andy Goryachev <[email protected]> wrote: > Good point about not overcomplicating build.gradle - it is a monster > already. > > Thanks! > -andy > > From: Marius Hanl <[email protected]> > Date: Tuesday, April 14, 2026 at 10:09 > To: Christopher Schnick <[email protected]>; [email protected] < > [email protected]>; Andy Goryachev <[email protected]> > Subject: Aw: Re: [External] : How to you run reproducers the best way? > > I would like to raise the point that we should not make the build.gradle > file any bigger. > > So if this standalone and e.g. included like I did in my maven publishing > PR, sure, this could be an idea. > > -- Marius > > Am 14.04.26, 17:39 schrieb Andy Goryachev <[email protected]< > http://oracle.com>>: > I would like to mention one more development in this area [0]: it would be > nice to integrate manual tests into the main gradle build, to be able to > build and run manual tests much like we build and run the system tests > right now. > > There are a few things I want to be able to do: > > * > run the manual tests individually or in sequence, all at once or a subset > * > be able to run from the IDE without creating a separate launch > configuration for each test > * > allow the manual tests to access common utility classes (such as > ManualTestWindow) > * > be able to run code snippets from source > > Do you think this might be useful generally? Is there any other features > that might be useful? > > Thanks, > -andy > > > > References > > [0] https://github.com/andy-goryachev-oracle/jfx/pull/13< > https://urldefense.com/v3/__https://github.com/andy-goryachev-oracle/jfx/pull/13__;!!ACWV5N9M2RV99hQ!IAkYBEF1uMGJaiIBwSyK7QRymtKaihczNDAUet3_7JsI9NAAhtKG3Ob4vk6AaN2H8GPewIZK-sRm_HMFHX8RliTj$ > > > > > > > From: Marius Hanl <[email protected]< > https://urldefense.com/v3/__http://web.de__;!!ACWV5N9M2RV99hQ!IAkYBEF1uMGJaiIBwSyK7QRymtKaihczNDAUet3_7JsI9NAAhtKG3Ob4vk6AaN2H8GPewIZK-sRm_HMFHRAxbUDn$ > >> > Date: Friday, April 10, 2026 at 12:52 > To: Christopher Schnick <[email protected]< > https://urldefense.com/v3/__http://xpipe.io__;!!ACWV5N9M2RV99hQ!IAkYBEF1uMGJaiIBwSyK7QRymtKaihczNDAUet3_7JsI9NAAhtKG3Ob4vk6AaN2H8GPewIZK-sRm_HMFHUx1TFYT$>>, > [email protected]<http://openjdk.org> <[email protected]< > http://openjdk.org>> > Subject: Re: [External] : How to you run reproducers the best way? > > I usually just build and publish the Branch into my local Maven > repository with: > > ./gradlew publishToMavenLocal -PMAVEN_PUBLISH=true > -PMAVEN_VERSION=custom-selection > > Similar to Andy, I have an repository with a lot of JavaFX Code and > Reproducers and I change the version in my pom.xml (defined as property) > > from: > > <javafx.version>26</javafx.version> > > to: > > <javafx.version>custom-selection</javafx.version> > > Same workflow with a Gradle based Project. And that makes it very easy > and fast to test something with different versions. > Unfortunately, as of now there are no Sources published (for debugging). > > Sometimes I also use the way that John mentioned in the past: > Copying the changed class (e.g. TableView) into a same named package > structure (javafx.scene.control) to effectively overwrite the JavaFX class. > This is only possible without a module-info. > > -- Marius > > > Am 09.04.2026 um 07:08 schrieb Christopher Schnick: > > Given a small reproducer code snippet that is not part of a test and > > not in the jfx repo, what is the quickest way to run this with a > > debugger attached with multiple different jfx builds/development > > branches to see the difference? I feel like my workflow is not optimal > > and would like to hear how others do it > > >
