Custom Intention Metadata: Problem in #4049
Hi,
I noticed a problem in build #4049 with plugins that provide intentions and with a
description by /intentionDescriptions/description.html etc. The following exception
happens when such an intention is selected in the "Intention Settings" dialog:
http://www.intellij.net/tracker/idea/viewSCR?publicId=57724
Is this an IDEA bug, or did something change in the way this data should be provided by
the plugin?
Thanks,
Sascha
请先登录再写评论。
Still the plugin is not providing intention descriptions.
Though I've corrected our code not to produce NPE but display "Under
construction" in Demetra branch.
Eugene.
"Sascha Weinreuter" <sascha.weinreuter@NOSPAM-cit.de> wrote in message
news:dluubd$avc$1@is.intellij.net...
>
>
>
BTW, the most common problem with missing resources in IDEA is packaging
into jars with wrong case.
While getResource() works perfectly well with case-insensitive file systems,
it starts failing once you package into jar.
Eugene.
"Eugene Vigdorchik (JetBrains)" <ven@intellij.com> wrote in message
news:dlvffb$k1n$1@is.intellij.net...
>
>
>> Hi,
>>
>> I noticed a problem in build #4049 with plugins that provide intentions
>> and with a
>> description by /intentionDescriptions/description.html etc. The following
>> exception
>> happens when such an intention is selected in the "Intention Settings"
>> dialog:
>> http://www.intellij.net/tracker/idea/viewSCR?publicId=57724
>>
>> Is this an IDEA bug, or did something change in the way this data should
>> be provided by
>> the plugin?
>>
>> Thanks,
>> Sascha
>
Hello Eugene,
I'm afraid I don't understand. The plugin does provide the descriptions which are
correctly shown in #3XXX builds. This is also the case with other 3rd-party plugins
(Refactor-X for example). I wouldn't bother you if there wasn't this clear change in
behavior between those builds.
So, has the way how to provide those descriptions (or their content) changed, and if it
did, is there a way to do this in a way that is compatible with both 3XXX and 4XXX builds?
Thanks,
Sascha
There were indeed some changes in this area, but nobody here believes they
could ruin the plugins. At the very least IPP still works as expected.
If you still believe this is IDEA problem, could you please point me out
some available plugin where the crash takes place? (I failed to find
Refactor-X
in the list of available plugins)
Eugene.
"Sascha Weinreuter" <sascha.weinreuter@NOSPAM-cit.de> wrote in message
news:dlvgen$so3$1@is.intellij.net...
>
>> Still the plugin is not providing intention descriptions.
>
>
>
Eugene,
That's what I noticed as well, and I didn't see an obvious difference between what IPP
does and what my plugin does, which confused me even more. My immediate feeling was that
it's some kind of classloading issue. Does IDEA treat system-plugins and user-plugins any
different in that respect?
Hmm, that's strange, but I'll investigate the issue a bit more and will create a simple
test case for you if possible. I didn't try this yet, but maybe IPP will exhibit the same
behavior if it's put into the user-plugins folder.
Sascha
IPP is very much not working as expected. If you click on an IPP intention under the Intentions settings panel, you get a stack trace as shown. Same with Refactor-J and Refactor-X intentions.
--Dave Griffith
Also disable intention in popup on bubble broken
"Dmitry Kashin" <no_mail@jetbrains.com> wrote in message
news:16807418.1132682099205.JavaMail.javamailuser@localhost...
This was intentionally removed. But the hint is still there, I know:(
:( Why? So useful feature as for me today config was lost and all code yellow :(
AFAIK, this was done to unify intentions UI with inspections.
"Dmitry Kashin" <no_mail@jetbrains.com> wrote in message
news:28272453.1132683703400.JavaMail.javamailuser@localhost...
yellow :(
Thanks for the info, Dave.
Will investigate this.
Eugene.
"Dave Griffith" <dave.griffith@cnn.com> wrote in message
news:18749649.1132679880117.JavaMail.javamailuser@localhost...
intention under the Intentions settings panel, you get a stack trace as
shown. Same with Refactor-J and Refactor-X intentions.
>
Well, that didn't turn out to change anything, but I still figured it out: The #4049 build
apparently doesn't like spaces or any other non-identifier characters in the description
paths. That's the significant difference between IPP and my stuff.
Hmm, that's probably because IPP as you ship it has been adapted to these changes. I don't
believe that changes in my code won't break anything almost every day, just to find out
that I'm wrong. I know the feeling ;)
So, to finally reveal the little secret: The descriptions work fine again if the
description directory is named like the intention class while in #3XXX it had to be
named after the family name. Alternatively, one can pass the name of the directory to
the registerIntentionAndMetaData() method, but that's deprecated now.
Maybe this helps someone else not to spend hours on investigating this...
Sascha
Eugene Vigdorchik (JetBrains) wrote:
In #4049, the ability to suppress the lightbulb for inspection quickfixes is gone and
clicking the bulb immediately executes the quickfix/intention (very dangerous, as
previously it did not). The introduction of a separate "disable intention" action can be
considered reasonable, but altogether it's a major change in the UI behavior without any
significant improvement.
My suggestion: Keep the old behavior (to either click an intention's bulb or press ]]>
to disable the hint) and add the inspection-like secondary action to disable it. People
are now used to that kind of behavior since several years that you don't really want to
change that in a dot-release.
If you really want to improve something, add an ability to turn off intentions completely,
i.e. in a way that they don't even show up any more when pressing alt-enter.
Sascha
I think I've always thought clicking the lightbulb to disable was unintuitive
and useless. You click the lightbulb in the editor to show the intentions, and
then clicking another lightbulb disables an individual intention? It doesn't
make sense, and I've seen new users get confused by it.
Sascha Weinreuter wrote:
>>AFAIK, this was done to unify intentions UI with inspections.
A dot-release is still not the right time to make a conceptual change here, especially if
existing functionality gets lost and introduces the risk of making unwanted changes when
following the old behavior.
I can understand that new users might be confused, but "fixing" that at the expense of
confusing existing users isn't good either.
Granted, #4049 is just the first EAP build and we might not have seen the complete picture
yet, but I'd rather add my 2c now than when it's too late.
Keith Lea wrote:
Hello Dave,
I can't reproduce such behaviour with IPP. Do you use IPP from 4049 build?
Seems that the problem corresponds to internationalization issues. Intention
descriptors were stored in intentionDesriptors/family name folder but due
to translation of family name this structure becomes inapplicable. Thus we
migrate it to intentionDescriptors/FQN folder. We've done such migration
for IPP but other plugins may be broken. We would try to find those descriptions
in the old place before reject.
Thank you.
-
Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"
Okay, my bad. I was using an old copy of IPP stuck in my user plugins directory. Works fine.
Just so I'm clear, though, if I want a plugin to provide intentions that work under both 5.0 and future versions, I need to have parallel intention description directories for each intention, one named after the class name of the intention and one named after the family name. Is that corrent? That seems to work, but I was wondering if there was an easier way.
--Dave Griffith
Hello Dave,
You can just use your old descriptor directories. I've fixed this issue in
4055.
New folder is essential for plugin if you want to internationalize it only.
But in this case you have to support both directories because of translation
'family name' to the target language :(
Thank you.
-
Anna Kozlova
JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"