Build with Maven (current dependencies, shaded fat jar)#529
Conversation
Declare all dependencies from Maven Central instead of hand-vendored lib/*.jar binaries, build the mixed Java+Scala src/ tree with scala-maven-plugin (joint compilation), and produce a self-contained shaded fat jar runnable as plm.core.ui.ProgrammersLearningMachine. Key points: - jgit upgraded from the 2013-era 3.2.0 to a current 6.10.x. The removed Repository.getRef(String) API is replaced by exactRef()/findRef() in GitUtils.java. - Scala toolchain moved to 2.12.20 (was 2.11.12). LangScala's in-memory compiler reporter (PLMReporter) is ported from the removed scala.tools.nsc.reporters.AbstractReporter to the 2.12 scala.tools.nsc.reporters.Reporter API (info0/Severity). - jython-standalone and jruby-complete replace the vendored jython + antlr3-runtime + asm and jruby + jnr jars; tools-openjdk8.jar dropped (the JDK provides javax.tools). - Resources (exercise templates, Swing assets, img/, lib/resources, lib/doc, ChangeLog) bundled via <resources>, mirroring the ant dist target. - i18n org.plm.i18n.Messages ResourceBundles generated from l10n/engine/*.po via the gettext-commons GenerateDefaultBundleTask (run through maven-antrun-plugin; the build-only gettext-ant-tasks jar is the one vendored jar kept). - Drop the now-unused vendored runtime jars under lib/. - Test sources (plm.test.*) compile (junit/mockito at provided scope, MockitoJUnitRunner import updated) but stay off the critical path (skipTests). (cherry picked from commit 510c87e8c47685735f0b42238c5c4d5c9658ad1a)
|
Hello, @vejeta thanks for your work, that's impressive :) I'm OK with the fact that your PR deprecates the previous one #527, because the @ebourg was too shy with my code base and tried not to be too intrusive. This PR does the right thing (I think). Also, not merging the translation updates in the PR is definitively the right thing to do here. I'm concerned by the fact that your version skips the test where I find it mandatory to run the tests on the CI. Maybe in another job or another step if you prefer, but skipping them seems difficult to me. I think this is the only reason why I didn't merge your work yet. Could you please update the PR so that we see what it brings? I also need to find again how to remove the appveyor builders. I would prefer to test the fat jar file on a bunch of non-linux images to ensure that they work, but I'm not sure of how to do that. Overall, I'm so glad you stubbled upon this project, I was really needing help to refresh the build chain of this package. Thanks again! |
|
Ahhh. Thanks for clarifications. I will have a look later so those tests can run, I will update the PR, and will have a thought about other OS.
|
…he AllTests suite in the main output, non-headless AWT, fork timeout
…ipTests=false); tests run by default, build job skips with -DskipTests
|
I'm sorry for the state of this code :-/ |
… suite The full AllTests suite spins up the Scala/Jython/JRuby engines and compiles in process per test (~45 min, times CI out), and some tests rely on force-killing a runaway loop, which no longer happens now that Thread.stop() is a cooperative Thread.interrupt(). Run the reliable core under xvfb; modernising the rest is follow-up.
The compiler-API port already targets 2.12, but Game.checkScala() still rejected 2.12.20 as 'too ancient' and told the user to install 2.11. Accept 2.12 (and, forward-tolerantly, 2.13). Matches the Game.java part of BuggleInc#527.
…the fat jar cross-platform (xvfb on Linux, native display on win/mac; gettext per OS)
…J-Swing) Drives the real Swing UI (under xvfb on Linux, native display on win/mac) rather than only the headless engine init, and runs on the same cross-platform matrix.
The GUI smoke test registers a MainFrame/ExerciseView as a Game listener (singletons) that leaked into JavaSimpleExerciseTest and NPE'd it -- surfacing only on Windows because surefire's class order differs per OS. A fresh fork per class isolates the state and makes the run order-independent.
|
No worries @mquinson, part of my my rediscovered passion is polishing software to make it shiny again :) This message is longer than I intended, but I want to cover all the changes. Essentially, I went to perform some tests, and made the CI (GitHub Actions) to be able to run The thing is that what it runs is a subset: GitSpyTest, GitUtilsTest, JavaSimpleExerciseTest I left the full AllTests suite out: it takes because it took more than 45 min and timed out (each test spins up the Scala/Jython/JRuby engines and compiles in process). Some tests seem to expect a runaway loop to be force-killed, which no longer happens (see below). Modernising that can be a good follow-up. Thanks to the tests: something to be fixed was discovered: Game.checkScala() rejected 2.12.20 as "too ancient"; it Remember that I replaced the removed Thread.stop() with a cooperative Thread.interrupt(), AppVeyor: This part is easy, we can just remove appveyor.yml in this PR; please disconnect the AppVeyor Regarding your question about testing Non-Linux jar: |
|
Hello @vejeta, many thanks! I actually already removed the AppVeyor integration, which is why this does not appear in the tests anymore. I think that the timeout is linked to the Thread.interrupt(), as I don't remember waiting that long for these tests. But that's sooo long that I hacked on PLM that I'm not certain. Disabling tests is always a sad instant, but I think that it's perfectly fine here. I may consider trying to implement what it takes to get the user code in an external process. I have a lot of work, but my dayjob project refuses to work, and I need a break anyway. I also need to think about a way to run the tests without the UI if possible. At some point. Your changes look great to me and I'm really pleased to merge this. Have a good $timeofday :) |
2 participants
Hi Martin, following up on the discussion started on #528.
I thought that the best way to prove this, was doing it with Maven.
This moves PLM's build to Maven so dependencies are declared and fetched from
Maven Central instead of the hand-added lib/*.jar binaries, and, so the project builds
against current library versions and
the deprecations show up in the build logs. "mvn -DskipTests package" produces
the same self-contained runnable jar for non-Debian users via
maven-shade-plugin. Builds on top of the merged #528.
Changes on this PR addressing your question.
pom.xml replacing build.xml; the vendored lib/*.jar are removed (one
build-time-only jar is kept: lib/gettext-ant-tasks-0.9.3.jar, not on Maven
Central).
Combined Java+Scala compilation with scala-maven-plugin (+ build-helper add-source
on src/, no source moves), so the Java and Scala files cross-reference.
i18n: the org.plm.i18n.Messages ResourceBundles are generated from
l10n/engine/*.po at build time (needs gettext: msginit/msgfmt on PATH).
maven-shade-plugin builds the runnable uber-jar (Main-Class
plm.core.ui.ProgrammersLearningMachine).
Dependencies now declared (current where possible)
compiles clean against 6.x with NO jgit deprecation warnings; the only breakage
was Repository.getRef(String), removed in 6.x -> migrated to exactRef()/
findRef().
4.5.14, jsch (mwiede fork) 0.2.18, gson 2.2.4, miglayout-swing 4.2,
rsyntaxtextarea 2.5.4, jline 2.14.6, gettext-commons 0.9.8, json-simple 1.1.1.
Source changes needed to build green
removed). NB this overlaps with @ebourg's Scala 2.12 PR Migrate to Scala 2.12 #527 -- happy to drop
it and rebase on Migrate to Scala 2.12 #527 if you'd rather land that first; I only needed scala 2.12
to compile.
Build notes
(ObjectClass not found); maven.compiler.release is 17. A maven-toolchains pin
would be worth adding.
git-fixture / mockito-1 patterns); re-enabling them is separate work.
Why this also helps Debian
The fat jar and the Debian package then come from the same pom: Debian builds it
offline against the system libraries (maven-debian-helper), no bundling, and the
build.xml jar-path patches the Debian package carries today disappear.