Den ons 29 juli 2026 kl 12:52 skrev Branko Čibej <[email protected]>:
> On 29. 7. 2026 10:58, Daniel Sahlberg wrote: > > > > Den ons 29 juli 2026 kl 04:32 skrev Jun Omae <[email protected]>: > >> On 2026/07/28 23:58, Daniel Sahlberg wrote: >> > Den mån 27 juli 2026 kl 00:09 skrev Jun Omae <[email protected] >> <mailto:[email protected]>>: >> > >> > > Is there a problem if we include the test classes? >> > >> > No direct issues have been found so far. However, static >> initializers within test classes are executed simply by loading the class. >> > >> > [[[ >> > $ grep -r 'static *{' subversion/bindings/javahl >> > >> >> subversion/bindings/javahl/tests/org/apache/subversion/javahl/UtilTests.java: >> static { >> > >> >> subversion/bindings/javahl/tests/org/apache/subversion/javahl/UtilTests.java: >> static { >> > ]]] >> > >> > >> > Thank you! >> > >> > I think I got it working on 1.14.x, successfully created a JAR file >> without the tests. >> > >> > It still seems to fail on trunk. Can you do the same steps above on >> trunk? >> > >> > Cheers, >> > Daniel >> > >> >> Hm, I get the same failures on trunk. >> It seems that the changes of the behavior is introduced in r1933892. >> At least, ./configure should stop and/or warn it if the junit is NOT >> optional when javahl enabled. >> >> [[[ >> $ /bin/sh autogen.sh >> $ ./configure --prefix=/dev/shm/svn/trunk --without-apxs --without-swig >> --without-swig-{perl,python,ruby} --enable-javahl >> --with-jdk=/usr/lib/jvm/java-11-openjdk-amd64 --without-junit >> PYTHON=/usr/bin/python3 >> $ make -j$(nproc) all >> $ make javahl >> >> $ find subversion/bindings/javahl -name '*.class' | wc -l >> 277 >> $ find subversion/bindings/javahl -name '*Test*.class' | wc -l >> 0 #==> tests/**/*.java are compiled yet. >> >> $ make install >> $ make install-javahl # Why this task builds tests/**/*.java? >> ... >> /dev/shm/subversion-trunk/subversion/bindings/javahl/tests/org/tigris/subversion/javahl/BasicTests.java:1708: >> error: cannot find symbol >> assertEquals("wrong revision from commit", >> ^ >> symbol: method assertEquals(String,long,int) >> location: class BasicTests >> /dev/shm/subversion-trunk/subversion/bindings/javahl/tests/org/tigris/subversion/javahl/BasicTests.java:1756: >> error: cannot find symbol >> assertEquals("wrong revision from update", >> ^ >> symbol: method assertEquals(String,long,int) >> location: class BasicTests >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> 100 errors >> ]]] >> > > Thanks for confirming! It seems like 1.15.x is also affected by this (I'll > bring it up on the release thread). > > To add three more data points to the discussion, I checked Fedora 43, 44 > and FreeBSD 14. The tests are present in Fedora's svn-javahl.jar but not in > FreeBSD's svn-javahl.jar. Obviously different distributors use different > options when building. That is unfortunate since we are distributing > different ABIs. > > I think it would be cleaner to have the tests in svn-javahl-tests.jar if > built. Maybe we want to install this alongside svn-javahl.jar. That way > Fedora and Ubuntu can keep distributing the tests and FreeBSD not, while > everyone's svn-javahl.jar is the same. > > Does that make sense? > > > > The following makes sense: > > 1. There is no regression in autotools. It is what it is. Note that > putting test classes in a separate jar has wider consequences than just the > ABI. For example, JavaHL tests would fail in autotools builds. We'd have to > change the way the classpath is constructed in `make check-*-javahl`. > autotools (in 1.14) produce different results depending on if you use --with-junit or without. Depending on how I read your arguments ("changing the ABI" below), it could be an ABI violation/bug that we sometimes produce a svn-javahl.jar without the test classes. > 2. No change is needed in 1.15.x. Autotools are consistent with earlier > releases and CMake doesn't build JavaHL. IFF we want to change this in > CMake for 1.15, then we have further questions to consider: > Autotools currently fail when building when using options that were working in 1.14. That for me is a regression. Changing build requirements and refusing to run configure is not a regression. More below. > > 2.1. CMake and Autotools/vcxproj should produce identical results given > identical options. In this case specifically I mean that the CMake build > should create the same lib/dll names and the same JavaHL jar (singular) as > the vcxproj generator. > > Agree that it should produce identical results given identical options. > > 3. Regardless of the answer to 2: If we decide to not include test classes > in svn-javhl.jar, then we have to consider how to mitigate the ABI change. > > Personally I'd prefer changing the build requirements to changing the ABI > in svn-javahl.jar. That means that --enable-javahl implies that JUnit is > mandatory. > Good! That is exactly what we need to figure out. Cheers, Daniel
