I'm using Intellij Idea 2022.2.3, while I wanna use jetty runner, the lastest jetty version is 1.4.20, and I got an error as below:
com.intellij.diagnostic.PluginException: The default implementation of method 'getId' is deprecated, you need to override it in 'class com.github.guikeller.jettyrunner.conf.JettyRunnerConfigurationFactory'. The default implementation delegates to 'getName' which may be localized, but return value of this method must not depend on current localization. [Plugin: JettyRunner-GK]
at com.intellij.diagnostic.PluginProblemReporterImpl.createPluginExceptionByClass(PluginProblemReporterImpl.java:23)
at com.intellij.diagnostic.PluginException.createByClass(PluginException.java:83)
at com.intellij.diagnostic.PluginException.reportDeprecatedDefault(PluginException.java:110)
at com.intellij.execution.configurations.ConfigurationFactory.getId(ConfigurationFactory.java:75)
at com.intellij.execution.impl.RunnerAndConfigurationSettingsImpl.writeExternal(RunnerAndConfigurationSettingsImpl.kt:265)
at com.intellij.execution.impl.RunnerAndConfigurationSettingsImpl.writeScheme(RunnerAndConfigurationSettingsImpl.kt:321)
at com.intellij.configurationStore.LazySchemeProcessor.writeScheme(scheme-impl.kt:65)
at com.intellij.execution.impl.RunConfigurationSchemeManager.writeScheme(RunConfigurationSchemeManager.kt:121)
at com.intellij.execution.impl.RunConfigurationSchemeManager.writeScheme(RunConfigurationSchemeManager.kt:21)
at com.intellij.configurationStore.schemeManager.SchemeManagerImpl.saveScheme(SchemeManagerImpl.kt:393)
at com.intellij.configurationStore.schemeManager.SchemeManagerImpl.save(SchemeManagerImpl.kt:333)
at com.intellij.configurationStore.Scheme_implKt.save(scheme-impl.kt:164)
at com.intellij.execution.impl.RunManagerImpl.getState(RunManagerImpl.kt:643)
at com.intellij.execution.impl.RunManagerImpl.getState(RunManagerImpl.kt:78)
at com.intellij.configurationStore.ComponentStoreImpl.commitComponent(ComponentStoreImpl.kt:334)
at com.intellij.configurationStore.ComponentStoreImpl.commitComponents$intellij_platform_configurationStore_impl(ComponentStoreImpl.kt:240)
at com.intellij.configurationStore.ComponentStoreWithExtraComponents.commitComponents$intellij_platform_configurationStore_impl(ComponentStoreWithExtraComponents.kt:94)
at com.intellij.configurationStore.ComponentStoreImpl$commitComponentsOnEdt$$inlined$withEdtContext$intellij_platform_configurationStore_impl$1.invokeSuspend(ComponentStoreImpl.kt:723)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
at com.intellij.openapi.application.constraints.BaseConstrainedExecution$Companion$scheduleWithinConstraints$1.invoke(BaseConstrainedExecution.kt:68)
at com.intellij.openapi.application.constraints.BaseConstrainedExecution$Companion.scheduleWithinConstraints(BaseConstrainedExecution.kt:71)
at com.intellij.openapi.application.constraints.BaseConstrainedExecution.scheduleWithinConstraints(BaseConstrainedExecution.kt:38)
at com.intellij.openapi.application.impl.BaseExpirableExecutorMixinImpl.access$scheduleWithinConstraints$s1153900543(BaseExpirableExecutorMixinImpl.kt:12)
at com.intellij.openapi.application.impl.BaseExpirableExecutorMixinImpl$scheduleWithinConstraints$$inlined$Runnable$1.run(Runnable.kt:19)
at com.intellij.openapi.application.TransactionGuardImpl.runWithWritingAllowed(TransactionGuardImpl.java:209)
at com.intellij.openapi.application.TransactionGuardImpl.access$100(TransactionGuardImpl.java:21)
at com.intellij.openapi.application.TransactionGuardImpl$1.run(TransactionGuardImpl.java:191)
at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:881)
at com.intellij.openapi.application.impl.ApplicationImpl$3.run(ApplicationImpl.java:513)
at com.intellij.openapi.application.impl.FlushQueue.doRun(FlushQueue.java:75)
at com.intellij.openapi.application.impl.FlushQueue.runNextEvent(FlushQueue.java:118)
at com.intellij.openapi.application.impl.FlushQueue.flushNow(FlushQueue.java:42)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:779)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:730)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:724)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:749)
at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:918)
at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:766)
at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$6(IdeEventQueue.java:450)
at com.intellij.openapi.progress.impl.CoreProgressManager.computePrioritized(CoreProgressManager.java:791)
at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$7(IdeEventQueue.java:449)
at com.intellij.openapi.application.TransactionGuardImpl.performActivity(TransactionGuardImpl.java:105)
at com.intellij.ide.IdeEventQueue.performActivity(IdeEventQueue.java:624)
at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$8(IdeEventQueue.java:447)
at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:881)
at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:493)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:207)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:92)
It looks like that plugin is out of date with your version of Intellij. It seems like the plugin has not been updated recently and is looking for a new maintainer.
You could
fork it and make the changes suggested in the error message (it doesn't seem like it would be too complicated)
Downgrade your intellij - probably a bad idea, but if you are really in a pinch might be the fastest way to get past this
Find an alternate solution; perhaps use the jetty maven plugin which appears to be still supported and has easy commands to run jetty (which can be put into an intellij run configuration)
I would recommend the last way. If you are already using maven, it will be pretty easy. If you are not using maven then it is a good opportunity to learn how to use it as it is very helpful for managing java projects
Although I am looking for a new maintainer I still am maintaining the plugin.
Please raise an issue on GitHub so this can be fixed, cheers!
Project link: https://github.com/guikeller/jetty-runner
PS: raised an issue on your behalf:
https://github.com/guikeller/jetty-runner/issues/81
Related
Going off the documentation here are Modules and other Geb DSL not expected to be recognized within a Spock Spec with IntelliJ? This makes using Geb with IntelliJ a bit cumbersome with no DSL reference. I noticed from this question that the asker did some custom work to get IntelliJ to wrap and notice the Geb DSL.
My questions is am I doing something wrong or is this expected and has there been any progress on getting the Geb DSL recognized by IntelliJ?
If not does anyone have a workaround for this issue/limitation and or another IDE that does recognized the Geb DSL?
IntelliJ has support for Geb DSL, I've been using it for years and there are even tests in IntelliJ's codebase that confirm it's there.
If you could share how your code looks like and what exactly does not work for you then maybe we can find a problem with your setup or expectations. It would also be good to know whether you are using community edition or professional edition.
Please note that the issue discussed in the question you linked to has been fixed by me in this PR and is no longer present since IntelliJ 2018.2.
EDIT:
After reading your comments under my response I now understand what the problem is. Your expectation is that IntelliJ will be able to figure out what the page type at runtime is and provide you with autocompletion. I'm afraid that is simply not possible - you need to track current page instance in your code for IntelliJ to be able to infer types.
Note that tests in geb-example-gradle are written in the very concise, yet dynamic style which means that IntelliJ is not able to infer types. What you need to do is to use the strongly typed style as described in the documentation. That section of the docs could do with a bit of improvement because it's not precise - I've created a Github issue to track that.
Essentially, if you tweak GebishOrgSpec from geb-example-gradle to:
class GebishOrgSpec extends GebSpec {
def "can get to the current Book of Geb"() {
when:
def homePage = to GebishOrgHomePage
and:
homePage.manualsMenu.open()
then:
homePage.manualsMenu.links[0].text().startsWith("current")
when:
homePage.manualsMenu.links[0].click()
then:
at TheBookOfGebPage
}
}
then IntelliJ will provide you with autocompletion.
I'm using SQ 7.3-alpha1 with sonar-kotlin-plugin-1.0.1.965.jar. However, I cannot deactivate a special warning inside my Kotlin code for repositories in Spring Data where I need an "_" in a method name.
I tried both //NOSONAR and #Suppress("kotlin:S100") and #SuppressWarnings("kotlin:S100"). Any hint is appreciated.
You're not able to deactivate that issue because none of the mechanisms you're trying to use have been implemented for Kotlin.
Instead, you'll have to do this from the UI side.
Great news, https://jira.sonarsource.com/browse/SONARSLANG-373 is fixed in version 1.6 of Sonarslang. So an update to that version might improve the situation. I’ve not tested it yet, hence the cautious wording.
I have a new Java project started that is using Gradle (version 3.4.1) and IntelliJ. I used gradle init at the command line and then imported the project into IntelliJ, using the default wrapper (which is recommended, according the the IDE).
I have the following in the build.gradle file:
jar {
manifest {
attributes 'Main-Class': "com.testerstories.textadv.Voxam"
}
}
The attributes line, however, provides a consistent warning that says:
'attributes' cannot be applied to '(['Main-Class':groovy.lang.GString])'
The issue appears to be "incompatible types." But it's unclear what "attributes" is being "applied to". I would presume the manifest block. But then ... what does it want me to do exactly?
I realize this is a warning and I could just ignore it. I also realize I can block inspections. But in all the discussions about this, and I realize there are a few (although most of those seem to deal with 'groovy.lang.Closure'), I have yet to find anything that unambiguously states quite simply what the actual issue is and how to resolve it. I say "resolve it" in contrast to (1) just cover it up or (2) pretend it doesn't exist.
It concerns me that something that appears to be very basic Gradle usage is not recognized or is indicating a problem in one of the core IDEs that supports Java.
Finally, I'll note that before adding to the StackOverflow space, I had asked JetBrains support and their answer was to make sure my .iml file was indicating a "JAVA_MODULE" rather than a "WEB_MODULE", which I did verify. Their next answer was that I needed to provide (quoting directly) a "namespace to resolve the ambiguity, which should resolve erroneous type errors." Ironically, perhaps, that reply needed some ambiguity resolution of its own, but I have gotten no further responses.
UPDATE (RELATED TO ABOVE; BUT DIFFERENT CONTEXT)
If I use something like this in my Gradle:
systemProperties(System.getProperties())
I'm told that getProperties() is an ambiguous method call. Originally I thought that was unrelated to my original issue, but the IntelliJ inspector reports that this is also an issue with incompatible types.
The conclusion I'm reaching -- and what will probably be the "answer" -- is that Gradle and IntelliJ just don't play nice with each other in a variety of contexts.
I would like to use IntelliJ's feature, which converts Java code to Kotlin by simply copy-pasting from Java file to Kotlin file. It is working fine, but when I turn on IdeaVim plugin, it refuses to work anymore. I know Vim decently and I that's not the problem with my misunderstanding Vim edit modes. I am aware of How can I convert a part of Java source file to Kotlin? and answer by #yole saying that there is no other tool to do that.
But that answer was made over 3 months ago, and maybe some other tool appeared. So, my question is if someone found workaround to make IdeaVim plugin cooperate with Java to Kotlin conversion. I've already made a ticket on YouTrack: https://youtrack.jetbrains.com/issue/VIM-1103 but frankly, I am not so sure if it will be resolved.
Ok, guy from JetBrains answered my issue. The obvious workaround (which I didn't figure out) is to copy and paste from context menu. Then conversion question shows up. IMO it seems unlikely that IdeaVim plugin will support this feature by yanking and putting (Vim's copying and pasting), as from:
Running IDE actions on copy and paste might be a good idea, but we're not sure it wouldn't disrupt the workflow of the current users.
The vim plugin takes over the clipboard and past functions. When you type :actionlist you get a list of idea actions you can use in your .ideavimrc file to map keymaps to idea actions. Use :action COMMAND to execute the command.
I.e.:
norepmap <C-w>q :action VimWindowClose<cr>
closes the current window.
Furthermore, you can search for a particular action with :actionlist Past.
This lists
EditorPast <C-V> <S-ins>
among other things.
If you want to check if EditorPast ist the right command you can test it using :action EditorPaste.
Another way to make this work is to let idea handle the <C-v> shortcut. This can be archieved with the Settings -> Other Setting -> Vim Emulation settings. The handler (vim or idea) can be defined with that setting.
We're using Maven at work at quite regularly we get the error message "The artifact has no valid ranges". After a long time of Googling and experimenting I realised what this error message means: The artifact does have valid ranges, just too many of them.
For example, my master POM has a dependency on superframework v.1.0 only, but there is also a transitive dependency on superframework v.0.5-0.9.
Until now, whenever I had such a problem I've looked at the (very cryptic) error message and sorta guessed which POM I needed to change - basically a lot of trial an error. The problem is that mvn dependency:tree doesn't work if you have a dependency resolution problem.
The Eclipse plugin sometimes helps a little, but sometimes it is way off.
Any tips on how to resolve these problems?
This might not be the expected answer but my advice would be to actually not use dependency ranges as they worsen build reproducibility.
I prefer to use fixed versions (which also make dependencies conflicts resolution easier, see the note at the bottom of 9.4.3. Dependency Version Ranges) and use intensively the Dependency Convergence report to manage them.
This isn't a direct answer to my question but rather a word of advice. I learned something new since askin the question: the order in which dependencies are listed in the POM files, much to my surprise, does matter.
So, if you include a dependency on
superframework [0.5,1.5)
it will fetch the latest available version, say 1.1.
If you then have a transitive dependency further down that includes
superframework [0.5, 1.0)
Maven will generate this misleading error, since it will not select anything other than the 1.1 it already has, even though it could just select 0.9 without producing a version conflict. If you swap the order, weirdly, it works.
Am I right in thinking that this is a flaw in Maven's behaviour?