Show Views in the Class' Structure tool window

[jgreffe]

Fixes #102

• jelly/jellytag files now have their own proper type / association / icon
• when displaying the structure view on a java class, all the related jelly/jellytag files having corresponding tree are displayed
• when displaying the structure view on a jelly/jellytag file, the related java class having corresponding tree is displayed

from java file src/main/java/this/is/a/test.java, we look for all jelly files contained in src/main/resources/this/is/a/test directory
from jelly file src/main/resources/another/test/*.jelly, we look for java class src/main/java/another/test.java

Manual tests with Intellij 2022.1.

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[duemir]

Whoa. This is interesting. Not what I imagined this feature to be. It pretty much adds the whole tree of the stapled class/view to the structured view of the other side. 🤔

The way I understand Stapler is that views are kinda like methods of the Class (e.g., doIndex() vs index.jelly). Hence my vision was to add views to the list of members of the class in a structured view. I didn't think about the other way around at all.

[duemir]

I've been on the fence about this for a while now. I am just unsure what kind of XML support features are lost versus what is gained by this.

Given structure view extension is "attached" to a PSI class, you kinda needed this. That said, you could have probably just used the XmlDocument.class and did the JellyFileTypeSchema.isJelly(parent.getContainingFile()) in the getChildren method.

[jgreffe]

Actually the JellyLanguage extends the XMLLanguage, therefore all XML features are included in Jelly language.
With this, checking the file instance against JellyFile is enough.

More, this method JellyFileTypeSchema.isJelly(parent.getContainingFile()) simply checks the extension and we redeclare jelly and jellytag, but we shouldn't anymore as it's already linked/declared here.
i.e : if we add a new extension for jelly, like jellyanothertag, we would need to update plugin.xml, and also JellyFileTypeSchema, which sounds like a duplicate/overhead to me (?)

[duemir]

I see what you mean. All the File Type, Language and PSI classes extend corresponding XML ones, so theoretically all the extensions that look for those types should still work with these derived types. I suspected that this type of change is necessary to get proper JEXL integration, but I am not sure, and JEXL support is just too much work.

I got burned by doing incremental changes to the file types before. You can see it if you read through https://github.com/jenkinsci/idea-stapler-plugin/releases

There is also a question of what happens if the end-user made a manual association between jelly extension and XML file type. From my previous experience, manual assosciation takes precedence, so the introduction of a new file type might break some old setups.

I'll need to ponder and test some more.

which sounds like a duplicate/overhead to me (?)

It was duplication even before your change. It looked unavoidable. I used JavaFX plugin for inspiration when I implemented the file type checking in that way. With the introduction of the Jelly File type, those public static predicates should no longer be needed.

[jglick]

Like a fancier version of https://github.com/stapler/netbeans-stapler-plugin/blob/714a93faf266fd2e3175f7344fec05316a0a2803/stapler-plugin/src/main/java/org/kohsuke/stapler/netbeans/plugin/StaplerViewAction.java#L56 I guess.

[rsandell]

It would be nice to treat groovy views the same.

[duemir]

@jglick, not really. GotoViewAction is analogous but less feature reach. I wrote down Issue #12 to note the improvements that should get it closer to NetBeans analogue.

[duemir]

I cobbled this svg together based on built-in JSP and YAML icons. It will look more native in the IDE compared to the current stapler icon. Let us use it?
for reference https://plugins.jetbrains.com/docs/intellij/work-with-icons-and-images.html#platform-vs-custom-icons

[jgreffe]

It would be nice to treat groovy views the same.

Could be part of another dev?

[jgreffe]

@duemir: new jelly icon added

[jgreffe]

Build failed: 14:08:22 Timeout has been exceeded

[jgreffe]

Ok now

[duemir]

I'll build a snapshot and run it locally for a few days to see if I notice any regressions or anything.

[jgreffe]

@duemir : spotted an issue when creating unit tests : feature was not working correctly with nested inner classes.
It's fixed and also added unit tests for tricky behavior.

[duemir]

@jgreffe, the plugin is lacking in terms of tests, so any new ones are welcome. I'll pull and re-build and try to review.

[jgreffe]

@duemir : pushed unchecked warning fix

[duemir]

That last commit wasn't necessary. It just adds more noise to an already large review.

[jgreffe]

@duemir: reverted last commit

[jgreffe]

🎊