Bug - Fixed Published builds do not work on my system.

Veracity

Developer
Staff member
This may be related to my previous observation that if I build "shadowjar", svn operations do not work for me, but if I build "jar", they do.

I build the following myself using "./gradlew jar"

Code:
bash-3.2$ java -jar dist/KoLmafia-25815.jar
KoLmafia r25815
Build main-c19105f 17 (Eclipse Adoptium 17+35) Mac OS X aarch64 11.6

Currently Running on Mac OS X
Local Directory is /Users/pld/Library/Application Support/KoLmafia
Using Java 17

When I "validate VeracityMeatFarm.ash", it throws an exception parsing a comment inside a plural typed constant. I shared that stack trace elsewhere.

I downloaded r25812.

Code:
$ java -jar dist/KoLmafia-25812.jar
KoLmafia r25812
Build HEAD-4b7b2f1 16.0.1 (AdoptOpenJDK 16.0.1+9) Linux amd64 5.11.0-37-generic

Currently Running on Mac OS X
Local Directory is /Users/pld/Library/Application Support/KoLmafia
Using Java 17

I can "validate VeracityMeatFarm.ash" just fine. but when I try to execute it:

Code:
> VeracityMeatFarm.ash

Validating configuration.
VMF.SpacegateCommand: 'random', but you have not installed VeracitySpacegate
Correct those errors and try again.

And when I try to open the Script Manager:

Code:
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.
Unexpected error, debug log printed.

Where each of those is something like this:

Code:
Unexpected error, debug log printed.
class org.tmatesoft.svn.core.SVNException: svn: E155007: '/Users/pld/Library/Application Support/KoLmafia/svn/Ezandora-Guide-branches-Release' is not a working copy
org.tmatesoft.svn.core.SVNException: svn: E155007: '/Users/pld/Library/Application Support/KoLmafia/svn/Ezandora-Guide-branches-Release' is not a working copy
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:70)
    at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:57)
    at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.parseDir(SVNWCDb.java:1955)
    at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.parseDir(SVNWCDb.java:1846)
    at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.readKind(SVNWCDb.java:4024)
    at org.tmatesoft.svn.core.internal.wc17.SVNWCContext.readKind(SVNWCContext.java:432)
    at org.tmatesoft.svn.core.internal.wc17.SVNWCContext.readKind(SVNWCContext.java:426)
    at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgGetStatus.run(SvnNgGetStatus.java:40)
    at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgGetStatus.run(SvnNgGetStatus.java:27)
    at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20)
    at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21)
    at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239)
    at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294)
    at org.tmatesoft.svn.core.wc.SVNStatusClient.doStatus(SVNStatusClient.java:363)
    at org.tmatesoft.svn.core.wc.SVNStatusClient.doStatus(SVNStatusClient.java:422)
    at org.tmatesoft.svn.core.wc.SVNStatusClient.doStatus(SVNStatusClient.java:384)
    at net.sourceforge.kolmafia.svn.SVNManager.workingCopyToSVNURL(SVNManager.java:1643)
    at net.sourceforge.kolmafia.persistence.ScriptManager.updateRepoState(ScriptManager.java:143)
    at net.sourceforge.kolmafia.persistence.ScriptManager.updateRepoScripts(ScriptManager.java:101)
    at net.sourceforge.kolmafia.persistence.ScriptManager.<clinit>(ScriptManager.java:89)
    at net.sourceforge.kolmafia.swingui.ScriptManageFrame$ScriptManageTable.<init>(ScriptManageFrame.java:35)
    at net.sourceforge.kolmafia.swingui.ScriptManageFrame.<init>(ScriptManageFrame.java:83)
    at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
    at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
    at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
    at net.sourceforge.kolmafia.CreateFrameRunnable.runConstruction(CreateFrameRunnable.java:216)
    at net.sourceforge.kolmafia.CreateFrameRunnable.createFrame(CreateFrameRunnable.java:128)
    at net.sourceforge.kolmafia.CreateFrameRunnable.run(CreateFrameRunnable.java:114)
    at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:308)
    at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:771)
    at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:722)
    at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:716)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
    at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
    at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:741)
    at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
    at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
    at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
    at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
    at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

I did "./gradlew shadowjar" in my workspace.
I ran that jar file.
I attempted to open the Script Manager - and I got the identical slew of SVN errors as I got from the published build.

What does "gradlew jar" make a functional .jar file for me but "gradlew shadowjar" makes an unusable jar - at least as far as SVN operations?
 

fronobulax

Developer
Staff member
What does "gradlew jar" make a functional .jar file for me but "gradlew shadowjar" makes an unusable jar - at least as far as SVN operations?

Under some conditions a SVN error results in a "bad" local repo and KoLmafia never really recovers from that.

Would you consider using a non-mafia tool to verify that svn/Ezandora-Guide-branches-Release is not a valid repository and then repeat the experiment with the shadow jar?
 

Veracity

Developer
Staff member
Every one of those Unexpected errors is an "Not a valid repository" error.
Every one of them is a script that I can execute just fine.
Running VMF checks if VSG exists - using svn_exists( "veracity0-spacegate" ) - (it does, and can be executed just fine), but with shadowjar, it gets the SVN error.

Code:
> ash svn_exists( "veracity0-spacegate" )

Returned: false
It does exist. If I build with "jar", that function returns true. If I build with "shadowjar", it returns false.

What, exactly, is the difference in the svn library between those two methods of building?

Exactly what "non-mafia tool" can I use to "verify that ... is not a valid repository"?
Especially since I have every reason to believe it actually is a valid repository?
 

Veracity

Developer
Staff member
Code:
$ pushd ~/Library/Application\ Support/KoLmafia/svn/veracity0-spacegate
~/Library/Application Support/KoLmafia/svn/veracity0-spacegate ~/root/src/kolmafia
bash-3.2$ svn status
bash-3.2$ svn update
Updating '.':
At revision 295.
 

MCroft

Developer
Staff member
I tried your test cases with source code for 25816 and the last commit before the parser changes.
For me, with Java 17, I consistently was able to run with Jar or ShadowJar (or runShadow) and verify and execute VeracityMeatFarm.ash on the prior commit, but both failed with 25816.

I'm not 100% sure what's happening for you, but I am wondering if anything else is different. ShadowJar is the equivalent of the Maven Shade command; it makes fat jars. So, maybe when you're using Jar, it's pulling something from your classpath.

Can you try the source build prior to the parser changes? If I did it correctly, it's revision 4b7b2f136b9c09e14d4a9d142d0682e114ba7e84
 

fronobulax

Developer
Staff member
Every one of those Unexpected errors is an "Not a valid repository" error.
Every one of them is a script that I can execute just fine.

The validity of the repository and the ability to run a script are not directly related since the repository is a directory under svn and the runnable script is a different file under scripts or some other directory that KoLmafia allows scripts to be run from. The repository validity prevents a script from being updated but does not prevent a previous version of being run.

I used a SVN client to browse the local KoLmafia created repositories in svn and sometimes that client would detect errors. I used TortoiseSVN but I have no idea what a Mac would use.

On Windows the jar and shadowjar are almost the same size and so far my tools don't show any difference in SVN related classes. I'm still digging.
 

Veracity

Developer
Staff member
Can you try the source build prior to the parser changes? If I did it correctly, it's revision 4b7b2f136b9c09e14d4a9d142d0682e114ba7e84
I am not set up to know how to fetch and build that source. However, I built with 25817 - which no longer fails to execute my scripts.

With "jar":

Code:
> ash svn_exists( "veracity0-spacegate" )

Returned: true

With "shadowjar":

Code:
> ash svn_exists( "veracity0-spacegate" )

Returned: false

I have no idea what a "fat jar" is. I have never used Maven or Gradle. The size difference in the generated jar files is a few hundred kB.
Whatever is being added in the "fat jar" breaks the svn support in KoLMafia for me..
 

Veracity

Developer
Staff member
And by the way - that is the result I get with the kolmafia.us supplied "fat jars" as well; it is not an artifact of how _I_ built it on my own system. Although, it could be an issue with my run-time environment here. Since I don't know what a "fat jar" is providing, I can't even begin to imagine what could be different between my environment and yours.
 

MCroft

Developer
Staff member
I was thinking classpath issues. You might have a different svnkit on your system classpath. Or it may be something that's using JNI that doesn't get along with M1 Macs yet. But we're on the latest SVNKit, although a few other dependencies are a small number of versions behind.

Let me try with my Intel Mac and 25817 and drop in a log to see if we can see the difference.
Bash:
Michaels-MBP:kolmafia mcroft$ git pull .
From .
 * branch                HEAD       -> FETCH_HEAD
Already up to date.
Michaels-MBP:kolmafia mcroft$ ./gradlew clean shadowJar
Starting a Gradle Daemon (subsequent builds will be faster)

> Configure project :
[versioning] WARNING - the working copy has unstaged or uncommitted changes.

> Task :compileJava
/Users/mcroft/projects/kolmafia/lib/tab/CloseTabPaneUI.java:626: warning: [removal] Integer(int) in Integer has been deprecated and marked for removal
                this.mnemonicToIndexMap.put( new Integer( mnemonic ), new Integer( index ) );
                                             ^
/Users/mcroft/projects/kolmafia/lib/tab/CloseTabPaneUI.java:626: warning: [removal] Integer(int) in Integer has been deprecated and marked for removal
                this.mnemonicToIndexMap.put( new Integer( mnemonic ), new Integer( index ) );
                                                                      ^
/Users/mcroft/projects/kolmafia/lib/tab/CloseTabPaneUI.java:1058: warning: [removal] Integer(int) in Integer has been deprecated and marked for removal
                                        Integer index = (Integer) ui.mnemonicToIndexMap.get( new Integer( mnemonic ) );
                                                                                             ^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
3 warnings

> Task :getRevision

Revision: 25816-M

> Task :shadowJar
Execution optimizations have been disabled for task ':shadowJar' to ensure correctness due to the following reasons:
  - Gradle detected a problem with the following location: '/Users/mcroft/projects/kolmafia/dist/KoLmafia-25816-M.jar'. Reason: Task ':cleanDist' uses this output of task ':shadowJar' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency for more details about this problem.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.2/userguide/command_line_interface.html#sec:command_line_warnings

Execution optimizations have been disabled for 1 invalid unit(s) of work during this build to ensure correctness.
Please consult deprecation warnings for more details.

BUILD SUCCESSFUL in 24s
8 actionable tasks: 7 executed, 1 from cache

Michaels-MBP:kolmafia mcroft$ java -jar dist/KoLmafia-25816-M.jar

KoLmafia r25816-M
Build additional_fix_for_afterlife-0759421-M 16.0.1 (Azul Systems, Inc. 16.0.1+9) Mac OS X x86_64 10.16

Currently Running on Mac OS X
Local Directory is /Users/mcroft/Library/Application Support/KoLmafia
Using Java 16.0.1


Code:
> ash svn_exists( "veracity0-spacegate" )

Returned: false

> svn checkout https://svn.code.sf.net/p/veracity0/code/spacegate

Starting Checkout...
Validating repo...
Repo validated.
/Users/mcroft/Library/Application Support/KoLmafia/svn/veracity0-spacegate
A https://svn.code.sf.net/p/veracity0/code/spacegate/data
A https://svn.code.sf.net/p/veracity0/code/spacegate/data/SpacegatePlanetsAuxVeracity.txt
A https://svn.code.sf.net/p/veracity0/code/spacegate/data/SpacegatePlanetsVeracity.txt
A https://svn.code.sf.net/p/veracity0/code/spacegate/data/Spacegate.0.tsv
A https://svn.code.sf.net/p/veracity0/code/spacegate/data/Spacegate.1.tsv
A https://svn.code.sf.net/p/veracity0/code/spacegate/data/SpacegatePlanetsAuxPublic.txt
A https://svn.code.sf.net/p/veracity0/code/spacegate/data/SpacegatePlanetsPublic.txt
A https://svn.code.sf.net/p/veracity0/code/spacegate/data/SpacegateTrophiesPublic.txt
A https://svn.code.sf.net/p/veracity0/code/spacegate/data/SpacegateTrophiesVeracity.txt
A https://svn.code.sf.net/p/veracity0/code/spacegate/scripts
A https://svn.code.sf.net/p/veracity0/code/spacegate/scripts/SpacegateImport.ash
A https://svn.code.sf.net/p/veracity0/code/spacegate/scripts/VeracitySpacegate.ash
A https://svn.code.sf.net/p/veracity0/code/spacegate/scripts/SpacegateExplorer.ash
A https://svn.code.sf.net/p/veracity0/code/spacegate/scripts/SpacegateData.ash
A https://svn.code.sf.net/p/veracity0/code/spacegate/scripts/SpacegateFixData.ash
https://svn.code.sf.net/p/veracity0/code/spacegate
At revision 295

Successfully checked out working copy.
Pushing local updates...
SpacegateFixData.ash => /Users/mcroft/Library/Application Support/KoLmafia/scripts/SpacegateFixData.ash
SpacegateData.ash => /Users/mcroft/Library/Application Support/KoLmafia/scripts/SpacegateData.ash
SpacegateExplorer.ash => /Users/mcroft/Library/Application Support/KoLmafia/scripts/SpacegateExplorer.ash
VeracitySpacegate.ash => /Users/mcroft/Library/Application Support/KoLmafia/scripts/VeracitySpacegate.ash
SpacegateImport.ash => /Users/mcroft/Library/Application Support/KoLmafia/scripts/SpacegateImport.ash
SpacegateTrophiesVeracity.txt => /Users/mcroft/Library/Application Support/KoLmafia/data/SpacegateTrophiesVeracity.txt
SpacegateTrophiesPublic.txt => /Users/mcroft/Library/Application Support/KoLmafia/data/SpacegateTrophiesPublic.txt
SpacegatePlanetsPublic.txt => /Users/mcroft/Library/Application Support/KoLmafia/data/SpacegatePlanetsPublic.txt
SpacegatePlanetsAuxPublic.txt => /Users/mcroft/Library/Application Support/KoLmafia/data/SpacegatePlanetsAuxPublic.txt
Spacegate.1.tsv => /Users/mcroft/Library/Application Support/KoLmafia/data/Spacegate.1.tsv
Spacegate.0.tsv => /Users/mcroft/Library/Application Support/KoLmafia/data/Spacegate.0.tsv
SpacegatePlanetsVeracity.txt => /Users/mcroft/Library/Application Support/KoLmafia/data/SpacegatePlanetsVeracity.txt
SpacegatePlanetsAuxVeracity.txt => /Users/mcroft/Library/Application Support/KoLmafia/data/SpacegatePlanetsAuxVeracity.txt
Done.
Requests complete.

> ash svn_exists( "veracity0-spacegate" )

Returned: true
 

MCroft

Developer
Staff member
So, making both and unzipping both, there are differences, mostly around dates and possibly block size.
Sometimes the file size is relevant. The first is the jar, the second is the shadowJar. The jar has picked up an older version of antler (which was the one used in SVN versions). SVNKit is the same, so it's not that.

Bash:
Michaels-MBP:antlr-runtime mcroft$ cat pom.properties
#Generated by Maven
#Tue Jul 19 09:36:08 PDT 2011
version=3.4
groupId=org.antlr
artifactId=antlr-runtime
/Users/mcroft/projects/kolmafia/dist/KoLmafia-25816-M/META-INF/maven/org.antlr/antlr-runtime
Michaels-MBP:antlr-runtime mcroft$ cat ~/projects/kolmafia/dist/KoLmafia-25816-M.shadowjar/META-INF/maven/org.antlr/antlr-runtime/pom.properties
#Generated by Maven
#Tue Mar 25 07:04:24 CDT 2014
version=3.5.2
groupId=org.antlr
artifactId=antlr-runtime
 

MCroft

Developer
Staff member
What happens in IntlelliJ or another IDE? Can you run the gradle>application>run and gradle>application>runShadow targets in debug mode?
 

Veracity

Developer
Staff member
I have not yet updated my IntelliJ development environment to use the new github/gradle stuff. I'll see what I can do, in the next few days.
 

Veracity

Developer
Staff member
I have finally setup my IntelliJ to deal with the github/gradle stuff.

(I continue to develop, almost exclusively, with Emacs. I also updated emacs from 24.5 to 28.1 yesterday and built from sources to get a native Apple M1 architecture version, and I am happy so see that M-x grep and M-x find-grep no longer fail half the time with malloc errors, unlike when it was emulating Intel architecture. I also had to update/recompile ash-mode to use the latest cc-mode - and I took the opportunity to update the recognized syntax to have things like "try" and new built-in data types since the package was last updated in 2012...)

(Side observation: did you know that since that time, we added the following built-in data types - phylum thrall bounty servant vykea - but, unlike all other built-in primitive types, did not make them reserved words?)

I set up two run configurations to try out

"run" - uses the gradle "run" task.

- Gives me KoLmafia r0

in gCLI:
Code:
> ash svn_exists( "veracity0-spacegate" )

Returned: false
(The same thing happens if I execute "./gradlew run" from my Terminal command prompt.)

"runShadow" - uses the gradle "runShadow" task.

- Gives me KoLmafia r26503-M

in gCLI:
Code:
> ash svn_exists( "veracity0-spacegate" )

Returned: false
(The same thing happens if I execute "./gradlew runShadow" from my Terminal command prompt.)

From my Terminal command prompt:
Code:
bash-3.2$ ./gradlew jar

BUILD SUCCESSFUL in 3s
6 actionable tasks: 1 executed, 5 up-to-date
bash-3.2$ java -jar dist/KoLmafia-26503-M.jar
in gCLI:
Code:
> ash svn_exists( "veracity0-spacegate" )

Returned: true

I guess I can run from IntelliJ for debugging - as long as I don't need to run scripts which depend on ASH svn functions.

But this is just bizarre.
 

heeheehee

Developer
Staff member
"run" - uses the gradle "run" task.

- Gives me KoLmafia r0
This one is "working as implemented" -- we're bundling the revision number in the jar via MANIFEST.MF, as opposed to the previous behavior where we actually overwrote the revision in the source before building.

gradle run does not actually build a jar, while runShadow and shadowJar do. As such, gradle run can't possibly know what the

(The same thing happens if I execute "./gradlew runShadow" from my Terminal command prompt.)
I can't reproduce this one. I could be holding it wrong, though. I haven't tried it through IntelliJ. It's also possible it's Mac-specific.
 

MCroft

Developer
Staff member
I can't reproduce this one. I could be holding it wrong, though. I haven't tried it through IntelliJ. It's also possible it's Mac-specific.
I can't reproduce this one on my (intel) Mac.



Bash:
Michaels-MBP:kolmafia mcroft$ git pull && ./gradlew runshadow --args=' --cli veracityspacegate help'
Already up to date.

> Configure project :
[versioning] WARNING - the working copy has unstaged or uncommitted changes.

> Task :getRevision

Revision: 26503-M

> Task :runShadow

KoLmafia r26503-M
Build main-279952f-M 17.0.3 (Eclipse Adoptium 17.0.3+7) Mac OS X x86_64 13.0

Currently Running on Mac OS X
Local Directory is /Users/mcroft/Library/Application Support/KoLmafia
Using Java 17.0.3

Available commands:

help - print this message

suggest [parameters] - select a planet to visit
visit [parameters] - select a planet to vist and go there

If you do not specify parameters, the script will use current settings to control selection

[... etc ...]

What do you get with ./gradlew v?

Bash:
Michaels-MBP:kolmafia mcroft$ ./gradlew -v

------------------------------------------------------------
Gradle 7.4.2
------------------------------------------------------------

Build time:   2022-03-31 15:25:29 UTC
Revision:     540473b8118064efcc264694cbcaa4b677f61041

Kotlin:       1.5.31
Groovy:       3.0.9
Ant:          Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM:          17.0.3 (Eclipse Adoptium 17.0.3+7)
OS:           Mac OS X 13.0 x86_64
 

Veracity

Developer
Staff member
Code:
bash-3.2$ ./gradlew -v

------------------------------------------------------------
Gradle 7.4.2
------------------------------------------------------------

Build time:   2022-03-31 15:25:29 UTC
Revision:     540473b8118064efcc264694cbcaa4b677f61041

Kotlin:       1.5.31
Groovy:       3.0.9
Ant:          Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM:          17.0.3 (Eclipse Adoptium 17.0.3+7)
OS:           Mac OS X 11.6.6 aarch64
 

MCroft

Developer
Staff member
rats, I was hoping for an easy solution there.

I think we're going to have to run verbose or debug to see what's different.

./gradlew --console verbose runShadow --args=' --cli veracityspacegate help; quit'

or --debug (don't post it, as it will warn you). Diffing the output may tell us something.
 

Veracity

Developer
Staff member
I will try this. I will you what I did yesterday. I spent an afternoon trying to figure out what differed.

I looked at the jar file - which is, essentially, a tar file.

- Antler was different.
- jni (whatever that is) was different.

I looked at what “shadow” does.

- it reorders things.
- if there are multiple things that give the same library, it picks one.

I ran with shadowjar.

- there were fifty or so installed SVN scripts that the installed svnkit said were not valid.
- I tried to “svn delete” the “invalid” ones, followed by svn checkout.
- some worked! svn_exists returned true!
- and then, other attempts failed. “Directory XXX is not empty”. It was empty. The “svn checkout” command had just created it.

I recompiled and restarted the non-shadow jar.
Every installed script is valid again.

Note that I should not be required to delete and reinstall a valid script.
Not that it works; the shadow svnkit cannot install previously installed scripts.

I saw a comment saying “classpath is wrong”. Umm. Surely that is specified by the .jar file? Surely simply running the .jar file doesn’t require my environment to specify such-and-such? Why in the world should my environment prevent a .jar file from executing, short of not being a good Java version?
 

Veracity

Developer
Staff member
I will run with —debug or something - but this has to be an issue in the shadow jar, not my environment.
 

Veracity

Developer
Staff member
Note that both jar and shadowjar choose exactly which classes are loaded/executed.

jar chooses classes used by svnkit which work.
shadowjar chooses classes used by svnkit which don’t work.

I am happy that shadowjar’s choices work for you.
Not for me.

Hopefully, we can control it.
 
Top