We're moving from SourceForge to GitHub!

[gausie]

After over 15 years developing KoLmafia using SVN and hosting it on SourceForge, the developer team has decided to move the source code and development to git and host it on GitHub. You can already find us over at https://github.com/kolmafia (with the main repository located at https://github.com/kolmafia/kolmafia) as we prepare the transition.

What's going to happen?

Our goal is to make the SVN repository read-only and check that the new repository contains all the changes and we're comfortable with the migration. This changeover will happen on the 26th of September 2021.

How does it affect me?

Once everything is up and running, if you just download prebuilt jars, you'll not notice the difference. Yay science.

If you prefer to build KoLmafia from source, you'll need to set up git on your machine and pull from our new repository location.

If you write patches for KoLmafia, you'll need to register for an account on GitHub - if you don't already have one. Making changes with git involves "forking" the repository, creating a new branch, adding any number of commits with your changes to that branch and then creating a "Pull Request" (with a title, description and link to any relevant issue on this forum) that we "pull" the changes from your branch into the main KoLmafia repository release branch. Discussion around your proposed changes will happen as comments on that Pull Request and your PR will be marked one of "accepted", "changes requested" or (rarely) "rejected".

We will continue to track issues on this forum, pending a review once the GitHub workflow is established. However, we will no longer accept patches submitted via the forum and change discussion should be kept as much as possible to the relevant Pull Request(s).

While we recommend moving your development process to git, GitHub offers an alternative method of interacting with its hosted repositories via an SVN client.

Why git?

• The addition of a "staging area" as well as better branching and merging make it easier for us to work on bigger changes
• Users and potential developers are increasingly more familiar with it vs SVN
• Many of the core developer team personally prefer using it!

Why GitHub?

• GitHub offers a lot of opportunities for new developers to get involved posting Pull Requests (instead of patch files) that can easily be reviewed line by line and appear next to the output of our unit testing and other CI (continuous integration) information.
• We can streamline the way the core developer team can review eachothers code through Pull Requests.
• SourceForge is unreliable and minimally maintained.

AAAAAAAAAAHH????
Aaaaaah!!!!!! Some of the core developer team are going to be online at the same time making sure everything is working properly before we finalize the changes. If we complete the process and you are still experiencing issues, please post in the Bug Reports forum. We'll probably miss something.

Thank you everyone for your support and we look forward to seeing you over on GitHub!

 

[MCroft]

I put a note into SourceForge linking here. There's also a "moved to" link when the time comes.

And I found Shwei's ancient homepage again. Not sure if it has anything worth salvaging, but it's an interesting historical artifact: https://kolmafia.sourceforge.io

 

[gausie]

And I found Shwei's ancient homepage again. Not sure if it has anything worth salvaging, but it's an interesting historical artifact: https://kolmafia.sourceforge.io

I actually recently updated it to say Java 1.8 and to use HTTPS. I'll archive it to a repository in our GitHub organisation for posterity and then make it redirect here or to GitHub

EDIT: Archive is now up and will be available at https://kolmafia.github.io/kolmafia.sourceforge.net.

 

[gausie]

Update: move is partially complete, we just need to fix some remaining Gradle issues.

 

[AlbinoRhino]

I pulled the github repo and ran "gradlew build" and it claims the build was successful. Is all of this output expected? Or are they a result of the "remaining gradle issues"? My build time with ant and the sourceforge repo was about 20 sec and this setup appears to be about 2 minutes. Is that expected? (Not complaining about 2 minutes, just curious.)

I ended up with "KoLmafia-0.jar" (about 20 MB) in the dist folder. I haven't tried to use it.

C:\kolmafia-git\trunk>gradlew build

> Task :compileLibJava
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

> 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

> 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: 'C:\kolmafia-git\trunk\dist\KoLmafia-0.jar'. Reason: Task ':distTar' 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.0/userguide/validation_problems.html#implicit_dependency for more details about this problem.
- Gradle detected a problem with the following location: 'C:\kolmafia-git\trunk\dist\KoLmafia-0.jar'. Reason: Task ':distZip' 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.0/userguide/validation_problems.html#implicit_dependency for more details about this problem.
- Gradle detected a problem with the following location: 'C:\kolmafia-git\trunk\dist\KoLmafia-0.jar'. Reason: Task ':startScripts' 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.0/userguide/validation_problems.html#implicit_dependency for more details about this problem.

> Task :startShadowScripts
Execution optimizations have been disabled for task ':startShadowScripts' to ensure correctness due to the following reasons:
- Gradle detected a problem with the following location: 'C:\kolmafia-git\trunk\dist\KoLmafia-0.jar'. Reason: Task ':startShadowScripts' uses this output of task ':jar' 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.0/userguide/validation_problems.html#implicit_dependency for more details about this problem.

> Task :shadowDistTar
Execution optimizations have been disabled for task ':shadowDistTar' to ensure correctness due to the following reasons
- Gradle detected a problem with the following location: 'C:\kolmafia-git\trunk\dist\KoLmafia-0.jar'. Reason: Task ':shadowDistTar' uses this output of task ':jar' 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.0/userguide/validation_problems.html#implicit_dependency for more details about this problem.

> Task :shadowDistZip
Execution optimizations have been disabled for task ':shadowDistZip' to ensure correctness due to the following reasons
- Gradle detected a problem with the following location: 'C:\kolmafia-git\trunk\dist\KoLmafia-0.jar'. Reason: Task ':shadowDistZip' uses this output of task ':jar' 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.0/userguide/validation_problems.html#implicit_dependency for more details about this problem.

> Task :cloverInstrumentCodeForTest
[ant:javac] warning: [options] bootstrap class path not set in conjunction with -source 8
[ant:javac] 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;
[ant:javac] Method getTaskbarMethod = taskbarClass.getMethod( "getTaskbar", null );
[ant:javac] ^
[ant:javac] cast to Class for a varargs call
[ant:javac] cast to Class[] for a non-varargs call and to suppress this warning
[ant:javac] 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;
[ant:javac] taskbar = getTaskbarMethod.invoke( null, null );
[ant:javac] ^
[ant:javac] cast to Object for a varargs call
[ant:javac] cast to Object[] for a non-varargs call and to suppress this warning
[ant:javac] Note: Some input files use or override a deprecated API.
[ant:javac] Note: Recompile with -Xlint:deprecation for details.
[ant:javac] Note: Some input files use unchecked or unsafe operations.
[ant:javac] Note: Recompile with -Xlint:unchecked for details.
[ant:javac] 3 warnings
[ant:javac] warning: [options] bootstrap class path not set in conjunction with -source 8
[ant:javac] Note: Some input files use unchecked or unsafe operations.
[ant:javac] Note: Recompile with -Xlint:unchecked for details.
[ant:javac] 1 warning
[ant:javac] warning: [options] bootstrap class path not set in conjunction with -source 8
[ant:javac] 1 warning

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/7.0/userguide/command_line_interface.html#sec:command_line_warnings

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

BUILD SUCCESSFUL in 1m 58s
14 actionable tasks: 14 executed
C:\kolmafia-git\trunk>

 

[MCroft]

I pulled the github repo and ran "gradlew build" and it claims the build was successful. Is all of this output expected? Or are they a result of the "remaining gradle issues"? My build time with ant and the sourceforge repo was about 20 sec and this setup appears to be about 2 minutes. Is that expected? (Not complaining about 2 minutes, just curious.)

I ended up with "KoLmafia-0.jar" (about 20 MB) in the dist folder. I haven't tried to use it.

try gradlew shadowJar if you want the fat jar and it'll set the build number.

 

[fewyn]

Jenkins is currently building but not testing due to issues. So any updater scrips that were using Jenkins should work fine now.

 

[Rinn]

I pulled the github repo and ran "gradlew build" and it claims the build was successful. Is all of this output expected? Or are they a result of the "remaining gradle issues"? My build time with ant and the sourceforge repo was about 20 sec and this setup appears to be about 2 minutes. Is that expected? (Not complaining about 2 minutes, just curious.)

I ended up with "KoLmafia-0.jar" (about 20 MB) in the dist folder. I haven't tried to use it.

`gradlew build` also builds some extra stuff required for tests. You can just do `gradlew jar` now, I fixed the revision showing up as 0.

 

[AlbinoRhino]

Will try those when I can get back to it. Thanks to you all.

 

[fronobulax]

At some point I was told "gradle jar" was the gradle eqivalent for ant daily. Is that no longer correct?

 

[MCroft]

At some point I was told "gradle jar" was the gradle eqivalent for ant daily. Is that no longer correct?

It can be. But if we use the shadow plugin, shadowJar is the correct target.
Docs: https://imperceptiblethoughts.com/shadow/introduction/#benefits-of-shadow
Source: https://github.com/johnrengelman/shadow

Gradle plugin to create fat/uber JARs, apply file transforms, and relocate packages for applications and libraries. Gradle version of Maven's Shade plugin.

So, we can write our own tasks or use a very common plugin. Just like ANT or Maven.

 

[heeheehee]

I fixed the revision showing up as 0.

Awkwardly, this broke revision-setting for me, as I didn't have a remote isn't called origin, but I did have a branch called main tracking github/main. It's a simple enough fix; I can just rename my existing remote.

 

[fronobulax]

It can be. But if we use the shadow plugin, shadowJar is the correct target.
Docs: https://imperceptiblethoughts.com/shadow/introduction/#benefits-of-shadow
Source: https://github.com/johnrengelman/shadow

So, we can write our own tasks or use a very common plugin. Just like ANT or Maven.

The news that we are using the shadow plugin wasn't as well publicized as this list of targets: `gradle jar`, `gradle run`, `gradle test`, `gradle clover`, `gradle clean`.

What, if any, is the difference between gradle and gradlew.bat?

At the moment both gradle shadowjar and gradlew.bat fail for me with
Execution failed for task ':gitRevList'.

Might be local if it's only me.

 

[MCroft]

also, it depends on if you want to create a jar you're handing off to someone or if you just want to build and run.

If you just want to launch it ./gradlew clean runShadow is great.

We could add a target for daily that was just a daily.dependsOn("clean, runShadow")

 

[Rinn]

What, if any, is the difference between gradle and gradlew.bat?

The batch file downloads a specific version of gradle set for the repo and runs that, instead of running whatever gradle is installed on your system.

At the moment both gradle shadowjar and gradlew.bat fail for me with
Execution failed for task ':gitRevList'.

Might be local if it's only me.

Run `gradlew.bat --info --stacktrace :gitRevList` so I can see the output, it's working on CI and locally for me.

 

[MCroft]

The news that we are using the shadow plugin wasn't as well publicized as this list of targets: `gradle jar`, `gradle run`, `gradle test`, `gradle clover`, `gradle clean`.

It was about 3PM this afternoon. We really should create aliases.

What, if any, is the difference between gradle and gradlew.bat?

gradlew is a wrapper for gradle. It assures that most people can launch gradle easily.
gradlew.bat is a windows version of the gradlew wrapper for gradle.
gradle is a directory that leads to gradle-wrapper.jar

build.gradle is the equivalent of ANT's build.xml

At the moment both gradle shadowjar and gradlew.bat fail for me with
Execution failed for task ':gitRevList'.

Might be local if it's only me.

Are you in a git or svn repo? We probably don't support downloaded code yet.
does gradlew.bat gitRevList work?

 

[kazgar]

Oo exciting changes (i'm late on these ones, but working diffs are great news)

In a low priority bug report, I usually use the page here: https://ci.kolmafia.us/job/Kolmafia/changes to work out the latest changes and set the number for my wget of the jar, but it seems to be having with the revision version.

I'm probably in the minority and if i should set up another method, so be it.

 

[fronobulax]

OK. My problem mentioned upstream was my problem. I had assumed GitHub Desktop installed a command line client. It didn't. Fixed that, at least when my console is Cygwin. I can sort out a global solution for me, later.

Since it was a question I am trying to do the update/build cycle completely and independently in "git world".

I just built KoLmafia-25694-M.jar which I consider a success. I have no clue what I did to have unstaged or uncommitted changes in my working copy but that is probably just between me and my lack of git expertise.

I look forward to enough stability that we can document how to build and contribute and have that be up to date for more than a few hours For example on my system the only thing using Gradle is KoLmafia so I can install whatever version I am told to install. Can I thus ignore gradlew.bat or is using it a good habit to develop because it will handle possible changes in the future?

Since I tend to be cynical and a Naysayer I will express my delight that so much is already working and extend my thanks to those who made it happen. This migration was well beyond my skill set.

 

[heeheehee]

but it seems to be having with the revision version.

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?)

Can I thus ignore gradlew.bat or is using it a good habit to develop because it will handle possible changes in the future?

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.

 

[fewyn]

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.

Correct the gradle build is currently not cleaning up the dist directory of existing jars.