20933: Bundle resources found in lib/, unbundle jars. This fixes an issue with external licenses...

RSS Bot

Feed Reader
Bundle resources found in lib/, unbundle jars.

This fixes an issue with external licenses not working in the gradle
build, and also manages to reduce the jar size to be in line with
Ant's.

by heeheehee on 2021-09-15 12:20:52

M /build.gradle (view) (diff)
 

fredg1

Member
@heeheehee what is the point of line 21 of build.gradle?
I've had issues with my copy since the transition to gradle, and I just found out that it seems like it is the cause.

The lines in question:
Code:
sourceSets {
  main {
    java {
      srcDirs = [ 'build/generated-src' ]
      destinationDirectory.set(file('build/main'))
    }
    resources {
      srcDirs = [ 'src', 'lib' ]
      excludes = ['**/*.java'] <<<<<<<<<
    }
  }
 
  [...]
(that line is changed to
Code:
      excludes = ['**/*.java', '**/*.jar']
on this very commit, but it's the "**/*.java" that's important here).


Doesn't it mean that we're just... not looking at the source files from /src ?

This is what VScode automatically fills .classpath with as a result:

XML:
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
    <classpathentry excluding="**/*.java|**/*.jar" kind="src" output="bin/main" path="src">
        <attributes>
            <attribute name="gradle_scope" value="main"/>
            <attribute name="gradle_used_by_scope" value="main,test"/>
        </attributes>
    </classpathentry>
    <classpathentry kind="src" output="bin/lib" path="lib">
        <attributes>
            <attribute name="gradle_scope" value="lib"/>
            <attribute name="gradle_used_by_scope" value="lib"/>
        </attributes>
    </classpathentry>
    <classpathentry kind="src" output="bin/test" path="test">
        <attributes>
            <attribute name="gradle_scope" value="test"/>
            <attribute name="gradle_used_by_scope" value="test"/>
            <attribute name="test" value="true"/>
        </attributes>
    </classpathentry>
    <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8/"/>
    <classpathentry kind="con" path="org.eclipse.buildship.core.gradleclasspathcontainer"/>
    <classpathentry kind="output" path="bin/default"/>
</classpath>
which, as I understand, means:
  • Create 3 scopes.
  • First scope is "lib". Take its content from "/lib".
  • Second scope is "test". Take its content from "/test".
  • Third scope is "main". Take its content from "/src", but only the stuff that's in no way whatsoever related to Java. BTW, "test" might be interested in you.
None of these include the source files from /src in any way. Sure enough, the result is:
  • Lots of errors coming from every single file in /test, whining that it can't resolve any of the imports starting with "net.sourceforge.kolmafia".
  • Opening any .java file in /src gives the warning "<file> is not on the classpath of project KoLmafia, only syntax errors are reported".
Now, there's three possible causes to this:
  1. There's something either missing or superfluous in build.gradle
  2. VScode's Java extension isn't correctly generating the .classpath file
  3. VScode's Java extension isn't correctly reading it's own .classpath file
Could you help me with this?

(btw, in case it matters, removing the "**/*.java|" in the .classpath does fix my problem. It would just be nice to not have to do this manually every time I switch branch, and instead look for the source of the issue)
 

heeheehee

Developer
Staff member
This is correct. That's in a resources stanza, which is supposed to contain non-Java sources.


Right now, as part of the compileJava task (done by setVersion), we're copying all the sources to build/generated-src, as part of setting the revision in an idempotent fashion. That's likely why VSCode can't detect the actual sources.

@Rinn has a pull request to instead bundle build/revision.txt in Gradle builds instead of manually editing KoLConstants.REVISION as we do. I expect that should fix your problem; you're welcome to either patch it in yourself, or kindly request that Rinn commit that code.
 
Top