On Mon, Oct 16, 2023 at 9:16 AM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > > Den sön 15 okt. 2023 kl 06:50 skrev Nathan Hartman <hartman.nat...@gmail.com>: >> >> On Fri, Oct 13, 2023 at 1:58 PM Johan Corveleyn <jcor...@gmail.com> wrote: >>> >>> On Fri, Oct 13, 2023 at 5:35 PM Stefan Sperling <s...@apache.org> wrote: >>> > >>> > On Fri, Oct 13, 2023 at 08:43:59AM +0200, Daniel Sahlberg wrote: >>> > > Hi, >>> > > >>> > > There are quite a number of improvements waiting to be released. Can we >>> > > muster the energy to do a new release? >>> > > >>> > > In trunk there are a lot of changes that warrant a 1.15, but before >>> > > doing >>> > > that I think we should also go back to the discussion of changing the / >>> > > adding a checksum algorithm in the WC. That deserves a separate thread >>> > > and >>> > > I'm half way through summarising the previous discussions so I'd like to >>> > > hold back 1.15 for the moment. >>> > > >>> > > Still in 1.14 there have been a number of bugfixes that might be good to >>> > > get released. Maybe doing 1.14.3 first could set us up to do 1.15 a >>> > > little >>> > > later? >>> > >>> > The first problem to solve before the ball starts rolling would be >>> > finding a release manager. I don't have enough spare time to play RM >>> > this time around but I would support the RM as far as my time allows for. >>> > >>> > Doing 1.14.3 first sounds like a good plan. This would help potential >>> > new releases managers to get bootstrapped into the process. A major >>> > release tends to involve a little bit more effort because some new >>> > problems >>> > may only show up on specific operating system platforms during -rc >>> > testing. >>> >>> +1 >>> >>> -- >>> Johan >> >> >> >> Hi all, >> >> I agree that a 1.14.3 release makes sense for a first-time RM, to be >> followed by a 1.15.0 at a later stage. (Also, there are some unresolved >> issues regarding 1.15.0, such as the above-mentioned question of checksum >> algorithms, that may require more development, but 1.14.3 should be much >> more straightforward.) >> >> At this moment I cannot promise to volunteer for this cycle but I will try >> to do so. >> >> Before I do, I need to get my system bootstrapped properly. I can build SVN >> and run most of the testsuite, but one pesky longstanding issue I have had >> is with the JavaHL bindings. That will require a separate thread and I'll >> describe the issues there. I'll check my notes to see what else might be a >> showstopper on my end. > > > I've successfully built and tested the JavaHL bindings at one point and I > think I can dig out my notes to help you if needed. > >> >> >> If I can get set up and solve the problems I've encountered previously in a >> reasonable time frame (and everyone's help is appreciated of course) I'll >> volunteer. > > > That would be great! I'd volunteer to do the next release after this. > > There were some Docker scripts floating around (Both from CMike and from > Mark). Maybe we should figure out if these can be included in /tools as a > help to set up the environment and to execute the necessary steps. > > Kind regards, > Daniel
Hi all, Previously I mentioned I plan to RM for the upcoming 1.14.3 release. This being my first time, I need to solve some issues first. One of these, which has been a stumbling block for me since the beginning, is getting the JavaHL bindings to build and test successfully. I have made progress on this, but not a complete breakthrough yet. The progress was discovering that I need to have $JAVA_HOME set in my environment; without this, our build system (in build/ac-macros/java.m4) fails to find javac and assigns 'none' to JAVAC; then, much later, 'make check-javahl' tries to call this 'none', which unsurprisingly doesn't work. (I was surprised that the other logic in this AC_DEFUN couldn't find javac without $JAVA_HOME being set, but that's a subject for another thread.) The clue was the use of $JAVA_HOME there. I tried various values for $JAVA_HOME but nothing that seemed sensible worked; based on a StackOverflow answer [1], I ended up setting $JAVA_HOME as follows: $ export JAVA_HOME=$(readlink -f /usr/bin/javac | sed "s:/bin/javac::") On my system, this sets $JAVA_HOME to: /usr/lib/jvm/java-17-openjdk-amd64 This value seems a little strange IMHO but it finally got 'configure' to find the JDK successfully and got me past the longstanding 'none' problem! But then I promptly ran into the next issue: [[[ $ make check-javahl (snip) /usr/lib/jvm/java-17-openjdk-amd64/bin/java -Xcheck:jni "-Dtest.rootdir=/home/nathan/ramdrive/svndev/svn-1.14.x/subversion/bindings/javahl/test-work" "-Dtest.srcdir=/home/nathan/ramdrive/svndev/svn-1.14.x/subversion/bindings/javahl" "-Dtest.rooturl=" "-Dtest.fstype=" "-Djava.library.path=:/home/nathan/ramdrive/svndev/prefix/svn-1.14.x/lib" -classpath "subversion/bindings/javahl/classes:/home/nathan/ramdrive/svndev/svn-1.14.x/subversion/bindings/javahl/src:" "-Dtest.cleanup=" "-Dtest.tests=" org.apache.subversion.javahl.RunTests Error: Could not find or load main class org.apache.subversion.javahl.RunTests Caused by: java.lang.ClassNotFoundException: org.apache.subversion.javahl.RunTests make: *** [Makefile:530: check-apache-javahl] Error 1 ]]] If I understand correctly, there should be a file called 'RunTests.class' in one of the directories specified with -classpath above. Well, there are other .class files to be found there, but not RunTests.class. A search for RunTests with any (or no) extension in the 1.14.x tree gives these two RunTests.java (not .class) files: $ find . -name RunTests\* ./subversion/bindings/javahl/tests/org/apache/subversion/javahl/RunTests.java ./subversion/bindings/javahl/tests/org/tigris/subversion/javahl/RunTests.java Forgive me if this is something obvious, but I know almost nothing about the Java ecosystem. :-) I'll have to continue this exploration tomorrow, but I'm at least glad to finally have made progress on a longstanding stumbling block. Meanwhile, any clues would be appreciated! [1] https://stackoverflow.com/a/29622512 Cheers, Nathan
