Le Tue, 21 Jun 2022 10:30:20 +0200, Alexey Abramov via Guix-patches via a écrit : > Hi > > I am glad that you find these patches helpful. I tried to apply your > finalized patches, but seems like java-openjfx-build-web-js-test.patch > is still missing. > > Regarding the patches themselves, I agree with Ludo. They are indeed > hard to maintain. The best approach here would be to pack gradle, so > we could build not only 8.u202 but later versions as well. And more! > It seems like it can be build with ant at > e09125febb2abd4d5eb70714ff68cdc76ee7dc45. > > In the meantime what we can do is make a separate channel for openjfx. > I use openjfx for davmail only, which does provide 2fa for Microsoft > Exchange. I have been experiencing some font issues since the > beginning and would be happy to try the finalized build you made. > Thanks! > Although I agree that maintainability of these packages is going to be hard, I don't think it's so different from, say, maven :) Using Gradle would be the best solution here, but unfortunately, it depends at least on Kotlin for which there is currently no known bootstrap path. I've ended up building a 0.10.something version in a channel, but the next version I tried to build failed for unknown reasons (I think the previous version miscompiles the last version I could build). Even so, building from these old versions would require a lot of intermediate versions before we reach a recent Kotlin and it'll get worse everytime. I haven't found an alternative implementation we could use either. I don't see Gradle coming to Guix soon unfortunately. Using a separate channel wouldn't change the maintainability issue, and it would make openjfx much less discoverable, so I don't think it's a good solution. We should simply add more documentation and make sure we explain what's going on. It's difficult to follow, issues will be hard to fix, but I think it's pretty similar to Maven, where each upgrade brings new issues that are difficult to trace back to a cause and fix.