I have a jenkins.gdsl file defining some bindings I'm using in my Groovy script. In addition, I'd like to use the #TypeChecked annotation on my methods to get some guarantees about built code.
My jenkins.gdsl file looks like:
contributor(context(scope: scriptScope())) {
// some definitions
}
And then my script.groovy looks like:
#TypeChecked(extensions='jenkins.gdsl')
void doStuff() {
// ...
}
IntelliJ IDEA autocomplete works, but when building my project I get an error in my jenkins.gdsl file:
Error:Groovyc: groovy.lang.MissingMethodException: No signature of method: org.codehaus.groovy.transform.stc.GroovyTypeCheckingExtensionSupport.scriptScope() is applicable for argument types: () values: []
Removing (extensions='jenkins.gdsl') gets rid of this error, but then I lose my GDSL definitions when building, so that's a no-go.
It feels like the solution would involve bringing in IntelliJ's standardDsls. I am not at all sure how to do this, or whether it is in fact the correct approach.
#TypeChecked is a Groovy compiler annotation that can run some code during compilation.
But gdsl is an IntelliJ IDEA-specific script that's used only by the IDE to provide some completion and other coding assistance. It doesn't have anything in common with the compiler, and neither of those know anything of each other. So you can remove the extensions value, as it won't provide any typechecking during compilation.
Related
It is not really a Kotlin question, maybe an Intellij question, I don't know.
Assume we have a data class
data class Person(val name: String = "untitled", val age: Int = 20)
And we have a function
fun factory(cstr: ()->Person) : Person {
return cstr()
}
Then we can invoke factory(::Person) and obtain an instance of Person class with default constructor parameters.
The fun factory can be invoked successfully wherever. But in IntelliJ I get a red underline error
Look like the IDE failed to recognize that there is a default constructor.
However, If I change the code like that, the error goes away. Everything runs perfectly and no error is shown in the IDE.
I am using IntelliJ 2020.2 and Kotlin 1.4.10.
Maybe it is about some IntelliJ inspection rules, but I cannot find one related.
Further, it is a piece of old code that showed no error before (maybe 5 months ago). I am not sure what has bee change since then caused the error.
So the problem is why is Intellij show error for lambda version and not for KFunction version?
I assume invoking factory like this works fine:
factory(() -> Person())
Then it seems your version of the Kotlin IDE plugin does not handle constructor references well in this case. The compiler does, since the code works. If the IDE plugin version is the latest, please file a bug at https://youtrack.jetbrains.com/issues/KT
I reproduced the problem with old inference enabled in the build.gradle file: freeCompilerArgs += ["-XXLanguage:-NewInference"]. Please make sure you're using new (default) type inference in Kotlin 1.4+. So, remove the compiler argument, that should fix the IDE highlighting after Gradle project reimport into IDEA.
Can i write in my custom plugin some function like kotlin("jvm")?
plugins {
java
kotlin("jvm") version "1.3.71"
}
I want to write function myplugin("foo") in my custom plugin and then use it like
plugins {
java
kotlin("jvm") version "1.3.71"
custom.plugin
myplugin("foo")
}
How i can do it?
I think that plugins block is some kind of a macro expression. It is parsed and precompiled using a very limited context. Probably, the magic happens somewhere in kotlin-dsl. This is probably the only way to get static accessors and extension functions from plugins to work in Kotlin. I've never seen a mention of this process in Gradle's documentation, but let me explain my thought. Probably, some smart guys from Gradle will correct me.
Let's take a look at some third-party plugin, like Liquibase. It allows you to write something like this in your build.gradle.kts:
liquibase {
activities {
register("name") {
// Configure the activity here
}
}
}
Think about it: in a statically compiled language like Kotlin, in order for this syntaxt to work, there should be an extension named liquibase on a Project type (as it is the type of this object in every build.gradle.kts) available in the classpath of a Gradle's VM that executes the build script.
Indeed, if you click on it, you'll see something like:
fun org.gradle.api.Project.`liquibase`(configure: org.liquibase.gradle.LiquibaseExtension.() -> Unit): Unit =
(this as org.gradle.api.plugins.ExtensionAware).extensions.configure("liquibase", configure)
But take a look at the file where it is defined. In my case it is ~/.gradle/caches/6.3/gradle-kotlin-dsl-accessors/cmljl3ridzazieb8fzn553oa8/cache/src/org/gradle/kotlin/dsl/Accessors39qcxru7gldpadn6lvh8lqs7b.kt. It is definitelly an auto-generated file. A few levels upper in a file tree — at ~/.gradle/caches/6.3/gradle-kotlin-dsl-accessors/ in my case — there are dozens of similar directories. I guess, one by every plugin/version I've ever used with Gradle 6.3. Here is another one for the Detekt plugin:
fun org.gradle.api.Project.`detekt`(configure: io.gitlab.arturbosch.detekt.extensions.DetektExtension.() -> Unit): Unit =
(this as org.gradle.api.plugins.ExtensionAware).extensions.configure("detekt", configure)
So, we have a bunch of .kt files defining all that extensions for different plugins applied to the project. That files are obviously pre-cached and precompiled and their content is available in build.gradle.kts. Indeed, you can find classes directories beside those sources.
The sources are generated based on the content of the applied plugins. It is probably a tricky task that includes some magic, reflection and introspection. Sometimes this magic doesn't work (due too chatic Groovy nature) and then you need to use some crappy DSL from this package.
How are they generated? I see no other way, but to
Parse the build.script.kts with an embedded Kotlin compiler / lexer
Extract all the plugins sections
Compile them, probably against some mocks (remember that Project is not yet available: we're not executing the build.gradle.kts itself yet!)
Resolve the declared plugins from Gradle Plugin repository (with some nuances coming from settngs.gradle.kts)
Introspect plugin's artifacts
Generate the sources
Compile the sources
Add the resulting classes to the script's classpath
And here is the gotcha: there is a very limited context (classpath, classes, methods — call it whatever) available when compiling the plugins block. Actually, no plugins are yet applied! Because, you know, you're parsing the block that applies plugins. Chickens, eggs, and their problems, huh…
So, and we're getting closer to the answer on your question, to provide custom DSL in plugins block, you need to modify that classpath. It's not a classpath of your build.gradle.kts, it's the classpath of the VM that parses build.gradle.kts. Basically, it's Gradle's own classpath — all the classes bundled in a Gradle distribution.
So, probably the only way to provide really custom DSLs in plugins block is to create a custom Gradle distribution.
EDIT:
Indeed, totally forgot to test the buildSrc. I've created a file PluginExtensions.kt in it, with a content
inline val org.gradle.plugin.use.PluginDependenciesSpec.`jawa`: org.gradle.plugin.use.PluginDependencySpec
get() = id("org.gradle.war") // Randomly picked
inline fun org.gradle.plugin.use.PluginDependenciesSpec.`jawa`(): org.gradle.plugin.use.PluginDependencySpec {
return id("org.gradle.cunit") // Randomly picked
}
And it seems to be working:
plugins {
jawa
jawa()
}
However, this is only working when PluginExtensions.kt is in the default package. Whenever I put it into a sub-package, the extensions are not recognized, even with an import:
Magic!
The kotlin function is just a simple extension function wrapping the traditional id method, not hard to define:
fun PluginDependenciesSpec.kotlin(module: String): PluginDependencySpec =
id("org.jetbrains.kotlin.$module")
However, this extension function is part of the standard gradle kotlin DSL API, which means it's available without any plugin. If you want to make a custom function like this available, you would need a plugin. A plugin to load your plugin. Not very practical.
I also tried using the buildSrc module to make an extension function like the above. But it turns out that buildSrc definitions aren't even available from the plugins DSL block, which has a very constrained syntax. That wouldn't have been very practical anyway, you would have needed to make a buildSrc folder for every project in which you have wanted to use the extension.
I'm not sure if this is possible at all. Try asking on https://discuss.gradle.org/.
The Kotlin standard library has a neat function require which is something like a runtime assert:
#kotlin.internal.InlineOnly
public inline fun require(value: Boolean, lazyMessage: () -> Any): Unit {
contract {
returns() implies value
}
if (!value) {
val message = lazyMessage()
throw IllegalArgumentException(message.toString())
}
}
When I am debugging, I would like to be able to set a breakpoint in this function, just before the exception is thrown. Like this, I would have the entire stacktrace and local variables visible in the debugger once a requirement is broken. However, this doesn't seem to work:
At first I thought that this is because require is an inline function. I made an experiment with one of my inline functions and the debugger halts as expected.
As a workaround I tried to set the debugger to break on exceptions, but the framework I am working with (Spring) throws a barrage of exceptions on each application start, making it extremely tedious to ignore the irrelevant exceptions.
I would like to know how to make it work, but I am also interested about the why of "it doesn't work".
It's currently not possible to set breakpoints in Kotlin for functions marked with a InlineOnly annotation, and require is one of such functions. Inline functions marked with this annotation don't provide additional debug information in order to save a line from the call site untouched in stack-traces, but it also ruins setting breakpoints inside (https://youtrack.jetbrains.com/issue/KT-24306).
You have spotted one workaround - using exception breakpoints (https://www.jetbrains.com/help/idea/creating-exception-breakpoints.html). IllegalArgumentException would be the best class in this case.
If there're calls in your code that don't work, they might be replaced to custom function as another workaround.
(The answer was updated. The previous version erroneously claimed that breakpoints in require might work for some calls.)
When I execute the following experimental code subset at http://groovyconsole.appspot.com/
class FileHandler {
def rootDir
FileHandler(String batchName) {
rootDir = '.\\Results\\'+batchName+'\\'
}
}
//def fileHandler = new FileHandler('Result-2012-12-15-10-48-55')
An exception results:
java.lang.NoSuchMethodException: FileHandler.<init>()
When I uncomment the last line that instantiates the class, the error goes away.
Can someone explain why this is? I'm basically attempting to segregate the definition and instantiation of the class into 2 files to be evaluated separately. Thanks
I'm not sure of the exact implementation details behind http://groovyconsole.appspot.com/ (source linked to from there points to Gaelyk, which I've not looked over). I'd bet it's looking for a no-arg constructor for the class you've presented, in an effort to find something runnable. (note that if you provide that, it still won't work, as it wants a main() :/)
Running locally in groovyConsole will die a bit sooner, with the following error message:
groovy.lang.GroovyRuntimeException: This script or class could not be run. It should either:
- have a main method,
- be a JUnit test or extend GroovyTestCase,
- implement the Runnable interface,
- or be compatible with a registered script runner.
This is perhaps more descriptive and to the point. If you want to run some Groovy as a simple script, you'll need to supply a jumping-in point. The easiest way is an executable statement in your groovy file, outside of any class definition (e.g, uncommenting your instantiation statement). Alternatively, a class with a main method should do it. (see here).
If 2 files is how you want to break it up, you can save the class file def in one groovy file (e.g., First.groovy) and create a second (e.g., Second.groovy) with just your executable statements. (I believe the first one will be in the classpath automatically when you run groovy Second, if both are in same directory)
The new intellij upgrade (10.5) now shows a warning that some of the methods defined for a class are not being used. These methods are public and I plan on not using all of them as I have created them to support the API expected. I would like to disable this warning (not used for public methods in a class). Is there a way to do it?.
You can disable it for a single method like this
#SuppressWarnings("unused")
public void myMethod(){...}
IDEA 2016.3
In the upcoming version IDEA 2016.3 (preview version already available) it is now possible to adjust the inspection scope:
< IDEA 14.0
If you want to highlight unused public methods, please enable the "Settings|Inspections|Declaration redundancy|Unused declaration" global inspection.
If you want to highlight unused private methods, please enable the "Settings|Inspections|Declaration redundancy|Unused symbol" local inspection.
So, if you want to highlight unused private members, but do not highlight unused public members, turn off "Unused declaration" and turn on "Unused symbol".
Source
I've just tested it using IDEA 13.1.4, and it worked exactly as described.
IDEA 14.x
In IntelliJ IDEA 14.0.x the settings are under:
Settings | Editor | Inspections | Declaration redundancy | Unused symbol/declaration
In IntelliJ IDEA 14.1 the option appears to be gone..
Disable Settings | Inspections | Declaration redundancy | Unused Declaration code inspection. As an option you can create a custom scope for your API classes and disable this inspection only per API scope so that it still works in the rest parts of your project.
2018-2019
Here is the 2019 update for:
IntelliJ IDEA 2018.3.2 (Community Edition)
Build #IC-183.4886.37, built on December 17, 2018
Settings | Editor | Inspections | Declaration redundancy | Unused declaration
I think the best way to avoid the highlighting of that unused public methods is writing a couple of test for those methods in your API.
In the latest version, this options is under Settings>Inspections>Java>Declaration redundancy>Unused declaration>Methods uncheck options which are not required.
This is an old thread, but I ended up here faster than I could find a solution so I'm going to go ahead and share my findings.
First, I am not sure if we are working with the same language (JS here,) but fiddling with the GUI-based tools, here is what I ended up with.
The following code was giving me the infamous "not used" warning:
/**
* #class sample class
*/
var MyClass = function () {
return this;
};
/**
* Some public method
* #api public
*/
MyClass.prototype.myMethod = function () {
return null;
};
There goes the "Unused definition myMethod"
The inspector ended up suggesting to ignore this specific issue by adding
//noinspection JSUnusedGlobalSymbols
right on top of this specific method so that the following code no longer results in this warning:
//noinspection JSUnusedGlobalSymbols
/**
* Some public method
* #api public
*/
MyClass.prototype.myMethod = function () {
return null;
};
Other warnings (typoes etc..) still seem to show up, including unused local variables and parameters, so it seems to isolate this particular issue.
The downside is that it tends to pollute your code if you have lots of it...
I just clicked "suppress for statement" and webstorm prepended this:
//noinspection JSUnusedGlobalSymbols
When extending a library recently, I was also alerted by that "not used" inspection warning.
Think about why IntelliJ signals
Usually when doing refactoring all unused methods/parameters should be safe to be deleted (via Intellij's safe delete action).
This way the intend of IntelliJ (like Checkstyle and others) is to support our clean design. Since the unused methods are neither used internally (in src/java/main) nor externally tested (in src/java/test) they seem obsolete. So why not following the saying "When in doubt, throw it out".
When refactoring, that's mostly a true advice.
But if we are developing a library/API that is intended to be used by other codebases (modules/dependencies from the ouside), then we rather answer "When not used, get confused".
We are astonished about IntelliJ's warning. The methods should not be deleted, because they are actually intended to be used elsewhere. They are entry-points.
Then choose suitable solution
All of below solutions have one in commen:
Communicate through your code, so every IDE and developer can understood (e.g. add a test so it becomes used)
Tell your intent (e.g. to IntelliJ via reconfiguring Code Inspection)
Configure Inspection or Disable
As described in various earlier answers. With screenshots and navigation hints to IntelliJ's Code Inspection settings
Add a test
If you add a test for the unused (method, class etc.) you will benefit in 3 ways:
correctness: (previously) unused subject under test (SUT) is tested
communication: you clearly communicate to every reader, that and how your unused (method, class, etc.) should be used
clearance: now the unused finally got used. So IntelliJ's inspection would not find and warn anymore.
Add or mark as Entry Point
I saw the suggestion multiple times:
as optional dialog tab inside IntelliJ's Inspection Settings
as comment below top-ranked answer:
IMO better approach is to mark class as "entry point". – Tanya Jivvca Aug 18 at 8:46
in IntelliJ's forum: Code inspection: unused element - what is an entry point? (emphasis in below quote by me):
Add the element as an entry point. By default, all code in the global scope as well as tests is treated as reachable. If you know that a method or function is executed, you may add it as an entry point. The code inside the entry point is now executed and reachable, as well.
When you add an entry point, your source code files stay unaffected, and the element’s record is stored with the project under .idea\misc.xml.
Maybe the entry points funtion can work, where you can specify the code pattern that can disable the warning
Settings | Inspections | Declaration redundancy | Unused Declaration | entry point