We're moving from SourceForge to GitHub!

heeheehee said:
Yeah. It looks like we're now publishing the commit hash. Is it too much to ask you to look at, say, https://ci.kolmafia.us/job/Kolmafia/lastSuccessfulBuild/artifact/dist/ or https://ci.kolmafia.us/job/Kolmafia/lastSuccessfulBuild/ instead? (I'm not sure why there are so many artifacts in that folder. Maybe we're not cleaning them up?)


If you're using Cygwin, you can ignore gradlew.bat. Either way, both gradlew.bat and gradlew are shallow wrappers around the actual Gradle functionality, and should not generally need to change over time.
Click to expand...

But the preference is to use gradelw or gradlew.bat as appropriate and not just gradle as resolved by a command path, correct? The point of the w versions is to enforce a particular version of gradle for the build process regardless of what is installed on the system and used? Does gradle even need to be locally installed if one of the w versions is used? "w versions" is shorthand that resolves to the "gradlew" or "gradlew.bat".
 
gradlew fails to run under Cygwin erroring with several "command not found". Presumably that is because my Cygwin install is sparser than a typical *nix distro. I may identify the missing commands or just abandon it when I have git available to Windows.

ant daily deleted other KoLmafia jars in dist. The gradle shadowjar target did not. Should I be using a different target or am I just impatient?
 
fronobulax said:
But the preference is to use gradelw or gradlew.bat as appropriate and not just gradle as resolved by a command path, correct? The point of the w versions is to enforce a particular version of gradle for the build process regardless of what is installed on the system and used? Does gradle even need to be locally installed if one of the w versions is used? "w versions" is shorthand that resolves to the "gradlew" or "gradlew.bat".
Click to expand...
Yes use the wrapper. Yes, we actually encountered a build issue with the newest version of gradle but I don't remember the details, so the repo uses a slightly older version.. No it doesn't need to be installed.

fronobulax said:
ant daily deleted other KoLmafia jars in dist. The gradle shadowjar target did not. Should I be using a different target or am I just impatient?
Click to expand...
I'll update the gradle build to clean old jars after work today.
 
Rinn said:
Yes use the wrapper. Yes, we actually encountered a build issue with the newest version of gradle but I don't remember the details, so the repo uses a slightly older version.. No it doesn't need to be installed.


I'll update the gradle build to clean old jars after work today.
Click to expand...

I think it had something to do with the clover tests.
 
I copied gradlew to another file and then ran dos2unix. The other file worked under Cygwin. So my failure to run is almost certainly some kind of EOL problem created by how I have Cygwin configured, and what git pulls to a Windows box. I think this is a moot point since my intent will be to use the bat wrapper.

I uninstalled Gradle locally and things work.
 
Ah yeah if you clone on windows git will use \r\n and shell scripts won't work. I can fix that with .gitattributes so it will be correct regardless of host OS, I'll do that as well tonight.
 
fronobulax said:
ant daily deleted other KoLmafia jars in dist. The gradle shadowjar target did not. Should I be using a different target or am I just impatient?
Click to expand...
Ant has a clean target daily depends on it.

I remember this precisely because I wrote it assuming I could just do a delete of the dist directory and ant would get us back to the same shape as if it were a fresh checkout.

The design was svn co looks just like “svn co && ant daily && ant clean”.

The flaw in this was that windows users often run the jar from the dist directory and it may have session and preferences in it. I made some users sad, and I learned my lesson.

We need to add something like

Code: 
clean.doLast {
    file('src/main/someFile.txt').delete()
    file('src/main/libs').deleteDir()
}
For any files we want to have cleaned with clean. We probably need a target daily that cleans and shadowJars. or maybe cleans and shadowRuns
 
Last edited:
Rinn said:
Ah yeah if you clone on windows git will use \r\n and shell scripts won't work. I can fix that with .gitattributes so it will be correct regardless of host OS, I'll do that as well tonight.
Click to expand...
Not necessary since the windows bat now works (because I installed git) but thank you.
 
Rinn said:
Yes use the wrapper. Yes, we actually encountered a build issue with the newest version of gradle but I don't remember the details, so the repo uses a slightly older version.. No it doesn't need to be installed.
Click to expand...

20890: Downgrade gradle wrapper to 7.0. 7.1 introduced an internal method...

Downgrade gradle wrapper to 7.0. 7.1 introduced an internal method (getPreviousCompilationData) whose implementation seems to interact poorly with our current project setup. This often caused transient test build failures with the unhelpful error message "Could not store compilation result"...
kolmafia.us

Maybe it is clover as fewyn suggests, I have no idea.
 
Here's the output I just got with "gradlew shadowJar" (I updated the repo manually with TortoiseSVN before running the command):

I again ended up with `KoLmafia-0.jar` in the dist folder.

C:\kolmafia-git\trunk>gradlew shadowJar
Starting a Gradle Daemon (subsequent builds will be faster)

> Task :compileJava
C:\kolmafia-git\trunk\lib\apple\dts\samplecode\osxadapter\OSXAdapter.java:120: warning: non-varargs call of varargs method with inexact argument type for last parameter;
Method getTaskbarMethod = taskbarClass.getMethod( "getTaskbar", null );
^
cast to Class for a varargs call
cast to Class[] for a non-varargs call and to suppress this warning
C:\kolmafia-git\trunk\lib\apple\dts\samplecode\osxadapter\OSXAdapter.java:121: warning: non-varargs call of varargs method with inexact argument type for last parameter;
taskbar = getTaskbarMethod.invoke( null, null );
^
cast to Object for a varargs call
cast to Object[] for a non-varargs call and to suppress this warning
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.
2 warnings

BUILD SUCCESSFUL in 25s
5 actionable tasks: 5 executed
C:\kolmafia-git\trunk>
Click to expand...
 
Hmm. What does git status in the root directory come back with?

Rich (BB code): 
Michaels-MBP:kolmafia mcroft$ git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    .idea/
    checkstyle.xml
    suppressions.xml
nothing added to commit but untracked files present (use "git add" to track)
 
As was mentioned somewhere else, I use Github desktop and don't actually have any command line git. I've been building from a separate repo checked out with TortoiseSVN. Maybe I should build in the one that Github desktop created?

In other news, the jar that I created seems to be working fine. I saw your updates re: ant deprecation and will probably build again soon if you want me to try anything different.
 
Without supporting the unsupported, you might be able to set a property to get the version on the command line.
 
More experimenting. I deleted the Tortoise repo. I tried a build in a repo created by Github desktop. I got some errors and failure on that one regarding 'getRevList" or something...I stupidly closed the window and don't have the output. But it also looked like the build process was expecting command line git to be installed...it looked like it tried to use a git command. So currently I am getting ready to find/install command line git and then retry.
 
Successful build of "KoLmafia-25707.jar" after installing git.
Still getting all of the messages re: Taskbar in the output. Are they meaningful?


Output:
C:\github\kolmafia\kolmafia>gradlew shadowJar
Starting a Gradle Daemon, 1 incompatible and 2 stopped Daemons could not be reused, use --status for details

> Task :compileLibJava
C:\github\kolmafia\kolmafia\lib\apple\dts\samplecode\osxadapter\OSXAdapter.java:120: warning: non-varargs call of varargs method with inexact argument type for last parameter;
Method getTaskbarMethod = taskbarClass.getMethod( "getTaskbar", null );
^
cast to Class for a varargs call
cast to Class[] for a non-varargs call and to suppress this warning
C:\github\kolmafia\kolmafia\lib\apple\dts\samplecode\osxadapter\OSXAdapter.java:121: warning: non-varargs call of varargs method with inexact argument type for last parameter;
taskbar = getTaskbarMethod.invoke( null, null );
^
cast to Object for a varargs call
cast to Object[] for a non-varargs call and to suppress this warning
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.
2 warnings

> Task :compileJava
C:\github\kolmafia\kolmafia\lib\apple\dts\samplecode\osxadapter\OSXAdapter.java:120: warning: non-varargs call of varargs method with inexact argument type for last parameter;
Method getTaskbarMethod = taskbarClass.getMethod( "getTaskbar", null );
^
cast to Class for a varargs call
cast to Class[] for a non-varargs call and to suppress this warning
C:\github\kolmafia\kolmafia\lib\apple\dts\samplecode\osxadapter\OSXAdapter.java:121: warning: non-varargs call of varargs method with inexact argument type for last parameter;
taskbar = getTaskbarMethod.invoke( null, null );
^
cast to Object for a varargs call
cast to Object[] for a non-varargs call and to suppress this warning
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.
2 warnings

BUILD SUCCESSFUL in 25s
5 actionable tasks: 5 executed
C:\github\kolmafia\kolmafia>
Click to expand...
 
AlbinoRhino said:
Successful build of "KoLmafia-25707.jar" after installing git.
Still getting all of the messages re: Taskbar in the output. Are they meaningful?


Output:
Click to expand...
Yes and no.

Those are warnings in library code, but once we go to Java 11 or 17, we can get rid of those particular libs.
 
To add. I had only GitDesktop installed. I had problems with Gradle updating and later getting revision. Something suggested the build process could not find git. I installed git in Cygwin, built from within Cygwin and things worked. I then installed a git command line client for Windows and things worked in Windows.

Our build process requires a git command line client to be installed/available and we now have two people who expected GitHub Desktop to install one and were disappointed because one wasn't installed or gradle couldn't find it.
 
fronobulax said:
To add. I had only GitDesktop installed. I had problems with Gradle updating and later getting revision. Something suggested the build process could not find git. I installed git in Cygwin, built from within Cygwin and things worked. I then installed a git command line client for Windows and things worked in Windows.

Our build process requires a git command line client to be installed/available and we now have two people who expected GitHub Desktop to install one and were disappointed because one wasn't installed or gradle couldn't find it.
Click to expand...
You make a good point! We do depend on the git CLI. When we re-write our documentation, we should definitely include that.

We are currently calling out to the git command line to get the count (similar to calling out to subversion to the the revision in ANT). We can probably move to JGit and grgit (the gradle task), but it isn't any different than the way we were doing SVN.

I know we talked about including that as a way to minimize requirements, but it just didn't happen in time.
 
You must log in or register to reply here.
Back
Top