Incorrect classpath in eclipse
warjort opened this issue · 15 comments
Using ./gradlew eclipse generates the wrong eclipse classpath for the forge subproject.
The following would be an example of the changes needed to the generated forge/.classpath in architectury itself.
-
+
i.e. the forge project depends on the generated mcp jar rather than the common project directly
I can't see a trivial way to fix it from this page?
https://docs.gradle.org/current/dsl/org.gradle.plugins.ide.eclipse.model.EclipseClasspath.html
I actually don’t use eclipse so I don’t know how it works or how to fix it, if you have any other insights, please do share them
How to post xml in this issues page, inline code?
- <classpathentry kind="src" path="/common"/>
+ <classpathentry kind="lib" path="/common/build/libs/architectury-1.1.9999-mcp.jar" sourcepath="/common/src/main/java"/>
seems about right, you need to run common:build to update the mcp remapped version of the common module
https://docs.gradle.org/current/javadoc/org/gradle/plugins/ide/eclipse/model/Classpath.html
I imagine you would have to use the above api to hack the ClasspathEntry(s) in one of the closures of the eclipse plugin configuration?
What is wrong with the cp currently?
As it stands the forge project depends upon the common classes compiled over the fabric version of MC. But uses the MCP minecraft classes for its compile.
e.g. for architectury the ToolTipFlag class does not exist in the forge version but it is used implicitly in EventHandlerImplClient::event(ItemToolTipEvent) if you compile directly over common instead of using common-mcp.jar
the forge module should use the common-mcp as classpath, and that jar has mcp class names
Yes, that is what the above change to forge/.classpath does.
But changing this manually everytime you change project dependencies (including version changes) will be a pain.
I got some time to dig around to try to find the root cause and the eclipse plugin has some logic to not add the original project if a resolved artefact is a jar. see visitProjectDependency [here:]
(https://github.com/gradle/gradle/blob/master/subprojects/ide/src/main/java/org/gradle/plugins/ide/eclipse/model/internal/EclipseDependenciesCreator.java)
Beyond that I got lost in the spaghetti that is gradle, loom, etc. trying to work out what might not be setting the library element attribute properly. Or it might just be that the 2 references to the /common project in the dependencies confuses it?
Anyway adding the following to forge/build.gradle fixes the problem for the architectury project
import org.gradle.plugins.ide.eclipse.model.Library
eclipse {
classpath {
file {
whenMerged {
entries.removeAll { it.path == '/common' }
def commonmcp = new Library(fileReference(file('../common/build/libs/architectury-' + project.version + '-mcp.jar')))
commonmcp.sourcePath = fileReference(file('../common/src/main/java'))
entries += commonmcp
}
}
}
}
This feels very hacky, but it does work.
It seems like eclipse fails to distinguish between runtime and compile only dependencies
We are not supporting eclipse in the near future, I am adding a wontfix tag.
This issue became kind of irrelvant when using the same mappings for fabric and forge.
At least I haven't had a problem with it.
Why is eclipse no longer supported? You know visual studio uses the same code for gradle integration as well?
Minecraft run configs are created differently on each platform, and Arch Loom needs some extra run config features compared to upstream Loom, which are currently only implemented for IDEA and VS Code run configs. (There might also be something else, but this is one of the main issues.)
Ok, thanks for the info.
I personally don't use the run configs, so I think you could say eclipse only has limited support?
Anyway, I will close this issue.